Implementación del software SILICON LABS Wireless M-BUS Guía del usuario de AN451

Esta nota de aplicación describe la implementación de Silicon Labs de Wireless M-Bus utilizando una MCU Silicon Labs C8051 y EZRadioPRO®. Wireless M-bus es un estándar europeo para aplicaciones de lectura de contadores que utilizan la banda de frecuencia de 868 MHz.

Capas de pila

Wireless M-Bus utiliza el modelo IEC de 3 capas, que es un subconjunto del modelo OSI de 7 capas (consulte la Figura 1).

La capa física (PHY) se define en EN 13757-4. La capa física define cómo se codifican y transmiten los bits, las características del módem de RF (velocidad de chip, preámbulo y palabra de sincronización) y los parámetros de RF (modulación, frecuencia central y desviación de frecuencia).
La capa PHY se implementa mediante una combinación de hardware y firmware. El EZRadioPRO realiza todas las funciones de RF y módem. El EZRadioPRO se usa en modo FIFO con el manejador de paquetes. El módulo MbusPhy.c proporciona interfaz SPI, codificación / decodificación, lectura / escritura de bloques y manejo de paquetes y administra los estados del transceptor.
La capa de enlace de datos M-Bus se implementa en el módulo MbusLink.c. La interfaz de programación de aplicaciones de M-Bus consta de funciones públicas que se pueden llamar desde la capa de aplicación en el hilo principal. El módulo MbusLink también implementa la capa de enlace de datos. La capa de enlace de datos formateará y copiará datos del búfer de transmisión de la aplicación al búfer de transmisión de MbusPhy, agregando los encabezados y CRC necesarios.
La capa de aplicación en sí no es parte del firmware de M-bus. La capa de aplicación define cómo se formateará una amplia variedad de datos para su transmisión. La mayoría de los medidores solo necesitan transmitir uno o dos tipos de datos. Agregar una gran cantidad de código para acomodar cualquier tipo de datos al medidor agregaría códigos innecesarios y costos al medidor. Podría ser factible implementar una biblioteca o un encabezado file con una lista exhaustiva de tipos de datos. Sin embargo, la mayoría de los clientes de medición saben exactamente qué tipo de datos necesitan transmitir y pueden consultar el estándar para obtener detalles de formato. Un lector o rastreador universal podría implementar un conjunto completo de tipos de datos de aplicaciones en la GUI de la PC. Por estas razones, la capa de aplicación se implementa utilizando exampaplicaciones le para medidor y lector.

Estándares requeridos

EN 13757-4
EN 13757-4
Sistema de comunicación para contadores y lectura remota de contadores
Parte 4: Lectura del medidor inalámbrico
Lectura del radiómetro para funcionamiento en la banda SRD de 868 MHz a 870 MHz
EN 13757-3
Sistema de comunicación para contadores y lectura remota de contadores
Parte 3: capa de aplicación dedicada

IEC 60870-2-1:1992
Equipos y sistemas de telecontrol
Parte 5: Protocolos de transmisión
Sección 1: Procedimiento de transmisión de enlaces
IEC 60870-1-1:1990
Equipos y sistemas de telecontrol
Parte 5: Protocolos de transmisión
Sección 1: Formatos de cuadro de transmisión

Definiciones

M-Autobús—M-Bus es un estándar cableado para la lectura de contadores en Europa.
M-Bus inalámbrico—Bus M inalámbrico para aplicaciones de lectura de contadores en Europa.

Física—La capa física define cómo se codifican y transmiten los bits y bytes de datos.
API—Interfaz del programador de aplicaciones.

ENLACE-La capa de enlace de datos define cómo se transmiten los bloques y las tramas.
CDN—Verificación de redundancia cíclica.

FSK—Frecuencia de modulación por desplazamiento.
Chip-Unidad más pequeña de datos transmitidos. Un bit de datos se codifica como varios chips.

Módulo-Fuente de código AC .c file.

Descripción funcional de M-Bus PHY

Secuencia del preámbulo

La secuencia del preámbulo especificada por la especificación M-bus es un número entero que alterna ceros y unos. Un uno se define como la frecuencia más alta y un cero se define como la frecuencia más baja.
nx (01)
Las opciones de preámbulo para el Si443x son un número entero de nibbles que consta de unos y ceros alternados.
nx (1010)
Un preámbulo con un preámbulo adicional no sería un problema, pero, entonces, la palabra de sincronización y la carga útil se desalinearían un bit.
La solución es invertir todo el paquete configurando el bit del motor en el registro de control de modulación 2 (0x71). Esto invertirá el preámbulo, la palabra de sincronización y los datos TX / RX. Como consecuencia, los datos deben invertirse al escribir los datos TX o leer los datos RX. Además, la palabra de sincronización se invierte antes de escribir en los registros de la palabra de sincronización Si443x.

Palabra de sincronización

La palabra de sincronización requerida por EN-13757-4 es 18 chips para el Modo S y Modo R o 10 chips para el Modelo T. La palabra de sincronización para el Si443x es de 1 a 4 bytes. Sin embargo, dado que la palabra de sincronización siempre está precedida por el preámbulo, los últimos seis bits del preámbulo pueden considerarse parte de la palabra de sincronización; por tanto, la primera palabra de sincronización se rellena con tres repeticiones de un cero seguido de un uno. La palabra de sincronización se complementa antes de escribir en los registros Si443x.
Tabla 1. Palabra de sincronización para Modo S y Modo R

EN 13757-4	00	01110110	10010110	binario
EN 13757-4	00	76	96	hexagonal
almohadilla con (01) x 3	01010100	01110110	10010110	binario
almohadilla con (01) x 3	54	76	96	hexagonal
complementar	10101011	10001001	01101001	binario
complementar	AB	89	69	hexagonal

Tabla 2. Palabra de sincronización para el medidor en modo T a otro

SINCRONIZAR	SINCRONIZAR	SINCRONIZAR
PALABRA	PALABRA	PALABRA
3	2	1

Transmitir la longitud del preámbulo

El preámbulo mínimo se especifica para cuatro modos de funcionamiento diferentes. Es aceptable tener un preámbulo más largo de lo especificado. Restar seis chips para el preámbulo da el número mínimo de chips para el preámbulo Si443x. La implementación agrega dos pedazos adicionales de preámbulo en todos los modos de preámbulo corto para mejorar la detección y la interoperabilidad del preámbulo. El preámbulo del Modo S con un preámbulo extenso es muy extenso; por tanto, se utiliza el preámbulo mínimo. La longitud del preámbulo en nibbles se escribe en el registro de longitud del preámbulo (0x34). El registro de longitud de preámbulo determina el preámbulo sólo tras la transmisión. Las configuraciones mínimas de especificación y longitud del preámbulo se resumen en la Tabla 3.
Tabla 3. Transmitir la longitud del preámbulo

	EN-13757-4 mínimo		Si443x Preámbulo Establecer ing		Sincronizar Palabra	Total	extra
	nx (01)	papas fritas	Bocadillos	papas fritas	papas fritas	papas fritas	papas fritas
Preámbulo corto del Modo S	15	30	8	32	6	38	8
Preámbulo largo de Mode S	279	558	138	552	6	558	0
Modo T (medidor-otro)	19	38	10	40	6	46	8
Modo R	39	78	20	80	6	86	8

El preámbulo mínimo para la recepción está determinado por el registro de control de detección de preámbulo (0x35). Tras la recepción, el número de bits en la palabra de sincronización debe restarse del preámbulo mínimo especificado para determinar el preámbulo utilizable. El tiempo mínimo de asentamiento del receptor es de 16 chips si AFC está habilitado o de 8 chips si AFC está deshabilitado. El tiempo de establecimiento del receptor también se resta del preámbulo utilizable para determinar el ajuste mínimo para el registro de control de detección de preámbulo.

La probabilidad de un preámbulo falso depende de la configuración del registro de control de detección de preámbulo. Un ajuste corto de 8 chips puede resultar en un falso preámbulo detectado cada pocos segundos. La configuración recomendada de 20 chips hace que la detección de preámbulos falsos sea un evento poco probable. Las longitudes de preámbulo para Mode R y Mode SL son lo suficientemente largas para que se utilice la configuración recomendada.
Hay muy pocos beneficios en hacer que el preámbulo detecte más de 20 chips.
El AFC está desactivado para el Modelo S con un preámbulo corto y el Modelo T. Esto reduce el tiempo de estabilización del receptor y permite un ajuste de detección de preámbulo más largo. Con AFC desactivado, el Modo T puede usar la configuración recomendada de 20 chips. Se utiliza una configuración de 4 nibbles o 20 chips para el Model S con un breve preámbulo. Esto hace que la probabilidad de una detección de preámbulo falso sea ligeramente mayor para este modelo.
Tabla 4. Detección de preámbulo

	EN-13757-4 mínimo		Sincronizar Palabra	usable preámbulo	Asentamiento RX	Detectar mín.	Si443x Preámbulo Configuración de detección
	nx (01)	papas fritas	papas fritas	papas fritas	papas fritas	papas fritas	Bocadillos	papas fritas
Preámbulo corto del Modo S	15	30	6	24	8*	16	4	16
Preámbulo largo del modelo S	279	558	6	552	16	536	5	20
Modelo T (metro-otro)	19	38	6	32	8*	24	5	20
Modo R	39	78	6	72	16	56	5	20
*Nota: AFC deshabilitado

El receptor está configurado para interoperar con un transmisor usando el preámbulo mínimo especificado. Esto asegura que el receptor interoperará con cualquier transmisor compatible con M-bus.
La especificación Wireless M-Bus requiere un preámbulo muy largo para el Modo S1 de al menos 558 chips. Esto tomará alrededor de 17 ms solo para transmitir el preámbulo. El Si443x no requiere un preámbulo tan largo y no se beneficia de un preámbulo extenso. Si bien el preámbulo largo se considera opcional para el Modo S2, no hay razón para usar un preámbulo largo con el Si443x. Si se desea una comunicación unidireccional, el Modo T1 proporcionará un preámbulo más corto, una mayor velocidad de datos y una mayor duración de la batería. Si se requiere una comunicación bidireccional utilizando el Modo S2, se recomienda un breve preámbulo.
Observe que el umbral de detección para el Model S con un preámbulo largo es mayor que el número de nibbles de preámbulo transmitidos para el Model S con un preámbulo corto. Esto significa que el receptor en Modo S de preámbulo largo no detectará un preámbulo de un transmisor en Modo S de preámbulo corto. Esto es necesario si el receptor en Modo S de preámbulo largo ha de recibir algún beneficio del preámbulo largo.
Tenga en cuenta que el receptor de modo S de preámbulo corto detectará el preámbulo y recibirá paquetes de un modo S de preámbulo corto
transmisor y un transmisor en Modo S de preámbulo largo; por lo que, en general, el lector de medidores debe utilizar la configuración del receptor Modo S de preámbulo corto.

Codificación/Decodificación

La especificación Wireless M-bus requiere dos métodos de codificación diferentes. La codificación Manchester se usa para el Modo S y el Modo R. La codificación Manchester también se usa para el enlace de otro a medidor en el Modelo T. El enlace de medidor a otro Modelo T usa 3 de 6 codificaciones.
1. Manchester codificado / decodificado
Históricamente, la codificación Manchester es común en los sistemas de RF para proporcionar un seguimiento y una recuperación de reloj sólidos mediante un módem simple y económico. Sin embargo, una radio moderna de alto rendimiento como la Si443x no necesita codificación Manchester. La codificación Manchester se admite principalmente por compatibilidad con los estándares existentes, pero la velocidad de datos para el Si443x se duplica efectivamente cuando no se utiliza la codificación Manchester.
El Si443x admite la codificación y decodificación Manchester de todo el paquete en hardware. Desafortunadamente, la palabra de sincronización no está codificada en Manchester. Se eligió intencionalmente una secuencia Manchester no válida para la palabra de sincronización. Esto hace que la codificación Manchester sea incompatible con la mayoría de las radios existentes, incluida la Si443x. Como consecuencia, la MCU debe realizar la codificación y decodificación Manchester. Cada byte de datos no codificados consta de ocho bits de datos. Usando la codificación Manchester, cada bit de datos se codifica en un símbolo de dos chips. Dado que los datos codificados deben escribirse en el FIFO de radio en ocho chips a la vez, se codifica y escribe un trozo de datos en el FIFO a la vez.
Tabla 5. Codificación Manchester

datos	Ox12		0x34		bytes
	Ox1	0x2	0x3	0x4	Bocadillos
	1	10	11	100	binario
chip	10101001	10100110	10100101	10011010	binario
Primero en entrar (FIFO)	BueyA9	BueyA6	BueyA5	Buey9A	hexagonal

Cada byte que se va a transmitir se pasa un byte a la vez a la función codificar byte. La función encode byte llamará a la función encode nibble dos veces, primero para el nibble más significativo y luego para el nibble menos significativo.
La codificación Manchester en software no es difícil. Comenzando por el bit más significativo, uno se codifica como una secuencia de chips "01". Un cero se codifica como una secuencia de chips "10". Esto se puede lograr fácilmente usando un bucle y cambiando dos bits para cada símbolo. Sin embargo, es más rápido usar una simple tabla de búsqueda de 16 entradas para cada bocado. La función encode Manchester nibble codifica un nibble de datos y luego los escribe en FIFO. Los chips se invierten antes de escribir en el FIFO para tener en cuenta los requisitos del preámbulo invertido.
Al recibir, cada byte en el FIFO consta de ocho chips y se decodifica en un nibble de datos. La función de bloque de lectura lee un byte a la vez del FIFO y llama a la función de byte de decodificación. Los chips se invierten después de leer el FIFO para tener en cuenta los requisitos del preámbulo invertido. Cada byte de chips codificados en Manchester se decodifica en una pequeña cantidad de datos. El nibble decodificado se escribe en el búfer RX utilizando la función de búfer RX write nibble.
Tenga en cuenta que tanto la codificación como la decodificación se realizan un nibble de datos a la vez sobre la marcha. La codificación en un búfer requeriría un búfer adicional dos veces el tamaño de los datos no codificados. La codificación y decodificación es mucho más rápida que la velocidad de datos más rápida admitida (100 k chips por segundo). Dado que el Si443x admite lecturas y escrituras de varios bytes en FIFO, existe una pequeña sobrecarga en el uso de lecturas y escrituras de un solo byte. La sobrecarga es de aproximadamente 10 µs para 100 chips codificados. El beneficio es un ahorro de RAM de 512 bytes.
2. Decodificación de codificación tres de seis
El método de codificación Tres de Seis especificado en EN-13757-4 también se implementa en el firmware de la MCU. Esta codificación se utiliza para el modo T de alta velocidad (100 k chips por segundo) de medidor a otro. El modelo T proporciona el tiempo de transmisión más corto y la batería de mayor duración para un medidor inalámbrico.
Cada byte de datos a transmitir se divide en dos nibbles. El nibble más significativo se codifica y se transmite primero. Una vez más, esto se implementa mediante una función de codificación de bytes que llama a la función de codificación nibble dos veces.
Cada trozo de datos se codifica en un símbolo de seis chips. La secuencia de símbolos de seis chips debe escribirse en el FIFO de 8 chips.
Durante la codificación, dos bytes de datos se codifican como cuatro nibbles. Cada mordisco es un símbolo de 6 fichas. Cuatro símbolos de 6 chips se agregan como tres bytes.
Tabla 6. Codificación de tres de seis

datos	0x12			0x34			bytes
	Ox1	0x2		0x3		0x4	Bocadillos
chip	15	16		13		34	octal
	1101	1110		1011		11100	binario
Primero en entrar (FIFO)	110100		11100010		11011100		binario
	0x34		BueyE2		OxDC		hexagonal

En software, la codificación tres de seis se implementa mediante tres funciones anidadas. La función codificar byte llamará a la función codificar nibble dos veces. La función encode nibble usa una tabla de búsqueda para el símbolo de seis chips y escribe el símbolo en las funciones Shift Three de Six. Esta función implementa un registro de desplazamiento de 16 chips en el software. El símbolo se escribe en el byte menos significativo del registro de desplazamiento. El registro se desplaza a la izquierda dos veces. Esto se repite tres veces. Cuando un byte completo está presente en el byte superior del registro de desplazamiento, se invierte y se escribe en el FIFO.
Dado que cada byte de datos se codifica como un byte codificado y medio, es importante borrar el registro de desplazamiento inicialmente para que el primer byte codificado sea correcto. Si la longitud del paquete es un número impar, después de codificar todos los bytes, todavía quedará un nibble en el registro de desplazamiento. Esto se maneja con el epígrafe como se explica en la siguiente sección.
Decodificar los tres de los seis codificados es el procedimiento inverso. Al decodificar, tres bytes codificados se decodifican en dos bytes de datos. El registro de desplazamiento de software se usa nuevamente para agregar bytes de datos decodificados. Se utiliza una tabla de búsqueda inversa de 64 entradas para la decodificación. Esto usa menos ciclos pero más memoria de código. La búsqueda del símbolo correspondiente en una tabla de búsqueda de 16 entradas lleva mucho más tiempo.
Postámbulo
La especificación Wireless M-bus tiene requisitos específicos para el postámbulo o el tráiler. Para todos los modos, el mínimo es de dos fichas y el máximo es de ocho fichas. Dado que la unidad atómica mínima para el FIFO es un byte, se usa un remolque de 8 chips para el Modo S y el Modo R. El postámbulo del Modo T es de ocho chips si la longitud del paquete es par o de cuatro chips si la longitud del paquete es impar. El postámbulo de cuatro chips para una longitud de paquete impar cumple con los requisitos de tener al menos dos chips alternos.
Tabla 7. Longitud postámbulo

	Longitud de postámbulo (chips)
	mín.	máximo	Implementación		secuencia de chips
Modo S	2	8	8		1010101
Modo T	2	8	4	(impar)	101
			8	(incluso)	1010101
Modo R	2	8	8		1010101

Manejador de paquetes

El controlador de paquetes en el Si443x se puede utilizar en un modo de ancho de paquete variable o en un modo de ancho de paquete fijo. El modo de ancho de paquete variable requiere un byte de longitud de paquete después de la palabra de sincronización y bytes de encabezado opcionales. Tras la recepción, la radio utilizará el byte de longitud para determinar el final de un paquete válido. En la transmisión, la radio insertará el campo de longitud después de los bytes del encabezado.
El campo L para el protocolo de bus M inalámbrico no se puede utilizar para el campo de longitud Si443x. Primero, el campo L no es la longitud real del paquete. Es el número de bytes de carga útil de la capa de enlace sin incluir los bytes CRC ni la codificación. En segundo lugar, el propio campo L se codifica utilizando la codificación Manchester o la codificación Tres de seis para el medidor de Modo T a otro.
La implementación utiliza el manejador de paquetes en modo de ancho de paquete fijo tanto para transmisión como para recepción. Tras la transmisión, la capa PHY leerá el campo L en el búfer de transmisión y calculará el número de bytes codificados, incluido el postámbulo. El número total de bytes codificados que se transmitirán se escribe en el registro de longitud del paquete (0x3E).
Tras la recepción, los dos primeros bytes codificados se decodifican y el campo L se escribe en el búfer de recepción. El campo L se utiliza para calcular el número de bytes codificados que se recibirán. El número de bytes codificados que se recibirán se escribe luego en el registro de longitud del paquete (0x3E). El postámbulo se descarta.
La MCU debe decodificar el campo L, calcular el número de bytes codificados y escribir el valor en el registro de longitud de paquete antes de recibir la longitud de paquete más corta posible. El campo L más corto permitido para la capa PHY es 9, lo que da 12 bytes sin codificar. Esto da 18 bytes codificados para el modelo T. Los primeros dos bytes ya han sido decodificados. Por lo tanto, el registro de longitud del paquete debe actualizarse en tiempos de 16 bytes a 100 kbps o 1.28 milisegundos. Esto no es un problema para un 8051 que se ejecuta a 20 MIPS.
El número de bytes que se recibirán no incluye el postámbulo, excepto el postámbulo de cuatro chips utilizado para los paquetes en Modo T con una longitud de paquete impar. Por lo tanto, el receptor no requiere un postámbulo, excepto para los paquetes de longitud impar del Modelo T. Este epígrafe solo es necesario para dar un número entero de bytes codificados. Se ignora el contenido del postámbulo; por tanto, si no se transmite el postámbulo, se recibirán y se ignorarán cuatro fragmentos de ruido. Dado que el número total de bytes codificados está limitado a 255 (0xFF), la implementación limita el campo L máximo para los diferentes modos.
Tabla 8. Límites de tamaño de paquete

	codificado		descifrado		M-Bus
	bytes		bytes		L-campo
	dic	hexagonal	dic	hexagonal	dic	hexagonal
Modo S	255	FF	127	7 °F	110	6E
Modo T (medidor-otro)	255	FF	169	A9	148	94
Modo R	255	FF	127	7 °F	110	6E

Estos límites normalmente están muy por encima del caso de uso típico de un medidor inalámbrico. La longitud del paquete debe mantenerse pequeña para obtener la mejor duración posible de la batería.
Además, el usuario puede especificar el campo L máximo que se debe recibir (USER_RX_MAX_L_FIELD). Esto determina el tamaño requerido para el búfer de recepción (USER_RX_BUFFER_SIZE).
Admitir un campo L máximo de 255 requeriría un búfer de recepción de 290 bytes y un máximo de 581 bytes codificados en Manchester. El manejador de paquetes debería estar deshabilitado y el registro de longitud de paquete no podría usarse en ese caso. Esto es factible, pero es más conveniente utilizar el manejador de paquetes, si es posible.

Uso de FIFO

El Si4431 proporciona un FIFO de 64 bytes para transmitir y recibir. Dado que el número de bytes codificados es 255, es posible que un paquete codificado completo no quepa dentro del búfer de 64 bytes.
Transmisión
En la transmisión, se calcula el número total de bytes codificados. Si el número total de bytes codificados, incluido el postámbulo, es inferior a 64 bytes, el paquete completo se escribe en el FIFO y solo se habilita la interrupción del paquete enviado. La mayoría de los paquetes cortos se enviarán en una transferencia FIFO.
Si el número de bytes codificados es mayor que 64, se requerirán múltiples transferencias FIFO para enviar el paquete. Los primeros 64 bytes se escriben en FIFO. Se habilitan las interrupciones Paquete enviado y TX FIFO casi vacío. El umbral de TX FIFO casi vacío se establece en 16 bytes (25%). Tras cada evento de IRQ, se lee el registro de estado 2. Primero se comprueba el bit de paquete enviado y, si el paquete no se ha enviado por completo, los siguientes 48 bytes de datos codificados se escriben en el FIFO. Esto continúa hasta que se hayan escrito todos los bytes codificados y se produzca la interrupción de paquete enviado.
1. Recepción
En la recepción, inicialmente, solo se habilita la interrupción Sync Word. Después de recibir la palabra de sincronización, se deshabilita la interrupción de la palabra de sincronización y se habilita la interrupción de FIFO casi completo. El umbral de FIFO casi completo se establece inicialmente en 2 bytes. La primera interrupción FIFO Almost Full se utiliza para saber cuándo se han recibido los dos bytes de longitud. Una vez que se ha recibido la longitud, se decodifica la longitud y se calcula el número de bytes codificados. El umbral RX FIFO casi completo se establece entonces en 48 bytes. El RX FIFO está casi lleno y las interrupciones de paquetes válidos están habilitadas. Tras el siguiente evento de IRQ, se lee el registro de estado 1. Primero, se verifica el bit de paquete válido y luego se verifica el bit FIFO casi completo. Si solo se establece el bit RX FIFO casi completo, los siguientes 48 bytes se leen del FIFO. Si se establece el bit de paquete válido, el resto del paquete se lee del FIFO. La MCU realiza un seguimiento de cuántos bytes se han leído y deja de leer después del último byte.

Capa de enlace de datos

El módulo de capa de enlace de datos implementa una capa de enlace compatible con 13757-4: 2005. La capa de enlace de datos (LINK) proporciona una interfaz entre la capa física (PHY) y la capa de aplicación (AL).
La capa de enlace de datos realiza las siguientes funciones:

Proporciona funciones que transfieren datos entre PHY y AL
Genera CRC para mensajes salientes
Detecta errores CRC en mensajes entrantes
Proporciona direccionamiento físico
Reconoce transferencias para modos de comunicación bidireccionales
Bits de datos de tramas
Detecta errores de encuadre en los mensajes entrantes

Formato de marco de capa de enlace

El formato de trama Wireless M-Bus utilizado en EN 13757-4: 2005 se deriva del formato de trama FT3 (Frame Type 3) de IEC60870-5-2. La trama consta de uno o más bloques de datos. Cada bloque incluye un campo CRC de 16 bits. El primer bloque es un bloque de longitud fija de 12 bytes que incluye el campo L, el campo C, el campo M y el campo A.

L-campo
El campo L es la longitud de la carga útil de datos de la capa de enlace. Esto no incluye el campo L en sí ni ninguno de los bytes CRC. Incluye el campo L, el campo C, el campo M y el campo A. Estos son parte de la carga útil PHY.
Debido a que el número de bytes codificados está limitado a 255 bytes, el valor máximo admitido para el campo M es 110 bytes para datos codificados en Manchester y 148 bytes para datos codificados en Modo T tres de seis.
La capa de enlace es responsable de calcular el campo L en la transmisión. La capa de enlace utilizará el campo L en la recepción.
Tenga en cuenta que el campo L no indica la longitud de la carga útil PHY o el número de bytes codificados. Tras la transmisión, la PHY calculará la longitud de la carga útil de la PHY y el número de bytes codificados. Tras la recepción, la PHY decodificará el campo L y calculará el número de bytes a decodificar.
Campo C
El campo C es el campo de control de tramas. Este campo identifica el tipo de trama y se utiliza para las primitivas del servicio de intercambio de datos de enlace. El campo C indica el tipo de trama: ENVIAR, CONFIRMAR, SOLICITAR o RESPONDER. En el caso de las tramas SEND y REQUEST, el campo C indica si se espera CONFIRM o RESPOND.
Cuando se utiliza la función básica de transmisión de enlace, se puede utilizar cualquier valor de C. Cuando se utilizan las primitivas del servicio de enlace, el campo C se completa automáticamente de acuerdo con EN 13757-4: 2005.
Campo M
El campo M es el código del fabricante. Los fabricantes pueden solicitar un código de tres letras a los siguientes web DIRECCIÓN: http://www.dlms.com/flag/INDEX.HTM Cada carácter del código de tres letras se codifica como cinco bits. El código de 5 bits se puede obtener tomando el código ASCII y restando 0x40 ("A"). Los tres códigos de 5 bits se concatenan para formar 15 bits. El bit más significativo es cero.
Al campo
El campo de dirección es una dirección única de 6 bytes para cada dispositivo. La dirección única debe ser asignada por el fabricante. Es responsabilidad de cada fabricante asegurarse de que cada dispositivo tenga una dirección única de 6 bytes. La dirección para los marcos de envío y solicitud es la dirección propia del medidor u otro dispositivo. Las tramas de datos de respuesta de confirmación se envían utilizando la dirección del dispositivo de origen.
CI-Campo
El campo CI es el encabezado de la aplicación y especifica el tipo de datos en la carga útil de datos de la aplicación. Si bien EN13757-4: 2005 especifica un número limitado de valores, las primitivas del servicio de enlace permitirán que se utilice cualquier valor.
CRC
El CRC se especifica en EN13757-4: 2005.
El polinomio CRC es:
X16 + x13 + x12 + x11 + x10 + x8 + x6 + x5 + x2 + 1
Tenga en cuenta que el CRC de M-Bus se calcula sobre cada bloque de 16 bytes. El resultado es que cada 16 bytes de datos requieren que se transmitan 18 bytes,

información adicional

Para obtener información adicional sobre la implementación de la capa de enlace, consulte “AN452: Guía para programadores de pila M-Bus inalámbrico”.

Gestión de energía

La Figura 2 muestra la línea de tiempo de administración de energía para un medidor example usando el Modo T1.

La MCU debe estar en modo de suspensión siempre que sea posible para ahorrar energía. En este example, la MCU está inactiva cuando el RTC está funcionando, cuando espera el inicio del cristal de radio y cuando transmite desde el FIFO. La MCU se activará a partir de la señal EZRadioPRO IRQ conectada a una activación de Port Match.
Al transmitir mensajes de más de un bloque, la MCU debe despertarse para llenar el FIFO (basado en la interrupción FIFO casi vacía) y luego volver a dormir.
La MCU debe estar en modo inactivo desde el oscilador de baja potencia o el oscilador en modo ráfaga cuando se lee desde el ADC. El ADC requiere un reloj SAR.
Cuando no esté en uso, el EZRadioPRO debe estar en modo de apagado con el pin SDN en alto. Esto requiere una conexión cableada a la MCU. Los registros de EZ Radio Pro no se conservan en el modo de apagado; entonces, el EZRadioPro se inicializa en cada intervalo RTC. La inicialización de la radio toma menos de 100 µs y conserva 400 nA. Esto da como resultado un ahorro de energía de 10 µJ, basado en un intervalo de 10 segundos.
El cristal EZRadioPRO tarda unos 16 ms en un POR. Esto es lo suficientemente largo para calcular el CRC de unos ocho bloques. La MCU volverá a dormir si completa todos los CRC antes de que el cristal se haya estabilizado. Si se requiere cifrado, también se puede iniciar mientras se espera en el oscilador de cristal.
La MCU debería funcionar a 20 MHz utilizando el oscilador de baja potencia para la mayoría de las tareas. Las tareas que requieren un tiempo de espera preciso deben usar el oscilador de precisión y el modo inactivo en lugar del modo de suspensión. El RTC proporciona suficiente resolución para la mayoría de las tareas. La línea de tiempo de administración de energía para el medidor T2 exampLa aplicación le se muestra en la Figura 3.

La implementación del transceptor debe optimizarse para el caso normal cuando el medidor se activa y no hay ningún lector presente. Los tiempos de espera mínimos / máximos de ACK son lo suficientemente largos para que sea posible utilizar el RTC C8051F930 y poner la MCU en modo de suspensión.
Se proporcionan opciones de construcción para lectores alimentados por USB o de red que no necesitan usar el modo de suspensión. El modo inactivo se utilizará en lugar de dormir para que el USB y UART puedan interrumpir la MCU.

Simplicity Studio
Acceso con un clic a MCU y herramientas inalámbricas, documentación, software, bibliotecas de código fuente y más. Disponible para Windows,
¡Mac y Linux!


Cartera de IoT www.silabs.com/IoT	SW / HW www.silabs.com/simplicidad	Calidad www.silabs.com/calidad	Soporte y comunidad comunidad.silabs.com

Descargo de responsabilidad
Silicon Labs tiene la intención de proporcionar a los clientes la documentación más reciente, precisa y detallada de todos los periféricos y módulos disponibles para los implementadores de sistemas y software que utilizan o tienen la intención de utilizar los productos de Silicon Labs. Los datos de caracterización, los módulos y periféricos disponibles, los tamaños de memoria y las direcciones de memoria se refieren a cada dispositivo específico, y los parámetros "típicos" proporcionados pueden variar y varían en diferentes aplicaciones.ampLos archivos descritos en este documento son solo para fines ilustrativos. Silicon Labs se reserva el derecho de realizar cambios sin previo aviso y limitación a la información del producto, especificaciones y descripciones aquí, y no ofrece garantías en cuanto a la precisión o integridad de la información incluida. Silicon Labs no tendrá ninguna responsabilidad por las consecuencias del uso de la información proporcionada en este documento. Este documento no implica ni expresa las licencias de derechos de autor otorgadas a continuación para diseñar o fabricar circuitos integrados. Los productos no están diseñados ni autorizados para su uso en ningún sistema de soporte vital sin el consentimiento específico por escrito de Silicon Labs. Un "Sistema de soporte vital" es cualquier producto o sistema destinado a respaldar o mantener la vida y / o la salud, que, si falla, se puede esperar razonablemente que resulte en lesiones personales importantes o la muerte. Los productos de Silicon Labs no están diseñados ni autorizados para aplicaciones militares. Los productos de Silicon Labs no se utilizarán bajo ninguna circunstancia en armas de destrucción masiva, incluidas (entre otras) armas nucleares, biológicas o químicas, o misiles capaces de lanzar tales armas.
Información de marca registrada
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® y el logotipo de Silicon Labs®, Bluegiga®, Bluegiga Logo®, Clockbuilder®, CMEMS®, DSPLL®, EFM®, EFM32®, EFR, Ember® , Energy Micro, Energy Micro logo y combinaciones de los mismos, “los microcontroladores más ecológicos del mundo”, Ember®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®, ISOmodem®, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY® , Telegesis, Telegesis Logo®, USBXpress® y otros son marcas comerciales o marcas comerciales registradas de Silicon Labs. ARM, CORTEX, Cortex-M3 y thumbs son marcas comerciales o marcas comerciales registradas de ARM Holdings. Keil es una marca registrada de ARM Limited. Todos los demás productos o nombres de marcas mencionados en este documento son marcas comerciales de sus respectivos propietarios.

laboratorios de silicio inc.
400 Oeste César Chávez
Austin, Texas 78701
EE.UU
http://www.silabs.com

Documentos / Recursos

Implementación del software SILICON LABS Wireless M-BUS AN451 [pdf] Guía del usuario
SILICON LABS, C8051, MCU y, EZRadioPRO, Wireless M-bus, Wireless, M-BUS, Software, Implementación, AN451

Referencias

Manual de usuario

Introducción