TESIS-Concentrador de Medidores Digitales para Sistema de Mediciones Remotas

INSTITUTO POLITÉCNICO NACIONAL
ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y

ELÉCTRICA
SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN
DEPARTAMENTO DE INGENIERÍA ELÉCTRICA
“Concentrador de medidores digitales para

sistema de mediciones remotas”
TESIS
QUE PARA OBTENER EL GRADO DE
MAESTRO EN CIENCIAS
EN INGENIERÍA ELÉCTRICA
PRESENTA:
ING. JOSÉ GUADALUPE FUENTES VELÁZQUEZ
JUNIO DE 2016, CIUDAD DE MÉXICO

Concentrador de medidores digitales para sistema de mediciones remotas Carta Cesión de Derechos
INSTITUTO POLTÉCNICO NACIONAL

SECRETARÍA DE INVESTIGACIÓN Y POSGRADO
CARTA CESIÓN DE DERECHOS
En la Ciudad de México, D.F. el día 30 del mes de Abril del año 2016, el que suscribe Ing.
José Guadalupe Fuentes Velázquez alumno del Programa de Maestría en Ciencias en
Ingeniería Eléctrica, con número de registro A140490, adscrito a la Sección de Estudios de
Posgrados e Investigación de la ESIME Unidad Zacatenco, manifiesto que es el autor
intelectual del presente trabajo de Tesis bajo la dirección del Dr. Raúl Ángel Cortés
Mateos y cede los derechos del trabajo titulado Concentrador de medidores digitales
para sistema de mediciones remotas, al Instituto Politécnico Nacional para su difusión,
con fines académicos y de investigación.
Los usuarios de la información no deben reproducir el contenido textual, gráficas o datos

del trabajo sin el permiso expreso del autor y/o director del trabajo. Este puede ser obtenido
escribiendo a las siguientes direcciones: ing.joseg.fuentesv@gmail.com y/o
rcortes@ipn.mx.
Si el permiso se otorga, el usuario deberá dar el agradecimiento correspondiente y citar la

fuente del mismo.
___________________________________
José Guadalupe Fuentes Velázquez
v
Concentrador de medidores digitales para sistema de mediciones remotas Resumen
Resumen
Este trabajo en particular se enfocó en la primera etapa conocida como Infraestructura de

Mediciones Avanzadas o AMI por sus siglas en inglés. Se comienza en este trabajo introduciendo
en los conceptos de Redes Eléctricas Inteligentes y de AMI’s explicando la estructura interna y las
principales tareas a realizar, para después hacer una propuesta de AMI.
El dispositivo en el cual se centró este trabajo de tesis fue el Concentrador, el cual se encarga de
monitorear de forma independiente a los Medidores Digitales que tenga asociados para obtener sus
datos de mediciones, datos que almacena y posteriormente pone a disposición de una red
informática para que de forma remota y en tiempo real esta pueda visualizarlos.
El prototipo de Concentrador de Medidores Digitales desarrollado en este trabajo se llamó CMD

por la abreviatura de sus iniciales, el cual ha sido implementado en una tarjeta de desarrollo
Raspberry Pi 2, esta tarjeta que más bien se asimila a una computadora personal es la encargada de
ejecutar varios programas para poder funcionar como servidor FTP (siglas en inglés de File
Transfer Protocol) el cual es un servidor que pone a disposición archivos de manera remota dentro
de una red informática, como servidor de escritorio remoto o VNC para permitir el control en
tiempo real de la AMI, como sistema de almacenamiento de datos o “datalogger” y como monitor
de la AMI manejando una red inalámbrica para comunicarse con los medidores digitales.
Para probar a este CMD se debieron implementar los demás componentes de una AMI. En primer
lugar un medidor emulado llamado MedidorE. Después un dispositivo para agrupar a varios
medidores cercanos llamado NodoM, encargado de comunicar a varios MedidorE con el CMD.
Después un sistema informático que se nombró Sistema Administrador, el cual consta de una red
local y una computadora personal con la cual se tiene acceso de forma remota al CMD y por lo
tanto a las mediciones y a la AMI en general.
Para intercomunicar al CMD con los NodoM se utilizó una red inalámbrica de tecnología LoRa la
cual es bidireccional, punto a punto y de largo alcance que permite la conexión a distancia con
múltiples dispositivos. Para comunicar a un NodoM con más de un MedidorE se utilizó una red
alámbrica multidispositivos RS485.
Se explican con detalle en esta tesis todos los diagramas, algoritmos y programas de cada uno de
los componentes desarrollados (MedidorE, NodoM, CMD y Sistema Administrador) así como
las pruebas realizadas para verificar su buen funcionamiento.
vii
Concentrador de medidores digitales para sistema de mediciones remotas Abstract
Abstract
This work particularly focused on first stage known as Advanced Measurement Infrastructure of
AMI for short. First introduced into the concepts of Smart Grid and AMI explaining the internal
structure and main tasks, and then make a proposal for AMI.
The device on which this thesis work focuses was the Concentrator, which is responsible for
independently monitor all Digital Meters associates with itself for get their measurement data, the
data stored and subsequently communicate that Concentrator with a computer network to display
all infirmation remotely and in real time.
The prototype Digital Meters´ Concentrator developed in this work was named CMD by the
abbreviation of his initials (in spanish), this was implemented in the development board Raspberry
Pi 2, this board is too similar to a personal computer and is responsible for running several
programs: a FTP (File Transfer Protocol) server to make available files remotely via a computer
network, a VNC (Virtual Network Computer) to access remotely and in real time to the CMD
board and the entire AMI, a datalogger to get and store all measurement data and a monitor program
to control and display the meters and the AMI via a wireless network.
To test this CMD was necessary to implement others components of an AMI. Firstly a emulated
meter called MedidorE. After that a local hub of meters called NodoM to communicate several
nearby MedidorE with the CMD. Finally a computer system named Sistema Administrador
which consists of a local area network and a personal computer through which you have remote
access to the CMD and therefore the measurements and the AMI in general.
To intercomunicate the CMD with the NodoM a wireless network with LoRa technology was used,
LoRa is a point to point and long range Network that allows remote connection to multiple devices.
To comunícate the NodoM with several MedidorE was used a RS485 network, this is a multi-
device wired network.
In this thesis explains in detail all the diagrams, algorithms and programs of each of the components
developed (MedidorE, NodoM, CMD and Sistema Administrador) besides the tests to verify
proper operation.
ix
Concentrador de medidores digitales para sistema de mediciones remotas Dedicatoria
Dedicatoria
Para aquella persona que ha caminado a mi lado los últimos años y que con dulzura y amor me
llena cada día, que con miradas y acciones me dice “sigue adelante”, que me recuerda que siempre
hay algo más por lo cual luchar, nuevas metas por alcanzar y mucha vida por recorrer, aquella
mujer que no ha soltado mi mano y con quien deseo siempre estar.
Para ti amiga mia, mi compañera y mi futura esposa:
Itzhae Guadalupe López Caso
xi
Concentrador de medidores digitales para sistema de mediciones remotas Agradecimientos
Agradecimientos
A mi padre, gracias a quien soy lo que soy en estos momentos y quien me han sabido motivar con
su ejemplo y palabras para seguir ambicionando conocimiento y superación.
A mi Madre, aquella mujer que no me ha dejado caer en la vida y quien con su amor y presencia
siempre me da razones de sobra para seguir adelante.
Al Dr. Raúl Ángel Cortés Mateos quien como profesor y asesor además de brindarme su apoyo y
guía durante el desarrollo de este trabajo de tesis, también me ha motivado con su ejemplo para
tomar decisiones tanto profesionales como de vida.
Al doctor Jaime Robles García quien como segundo vocal de la comisión revisora de esta tesis
aportó con sus puntos de vista para mejorar este trabajo, pero además quién gracias a sus relaciones
con CFE y proyectos de investigación dio pauta para elegir el tema que se desarrolló en esta tesis.
Al resto de los miembros de la comisión revisora de esta tesis; al Dr. Ricardo Octavio Mota
Palomino, al Dr. Daniel Olguín Salinas, al Dr. Domitilo Libreros y al Dr. David Sebastián Baltazar
quienes con sus observaciones me ayudaron a mejorar mi trabajo.
A mis compañeros, a mis profesores y a la SEPI-ESIME-ZACATENCO en general por darme la

oportunidad de realizar este paso tan importante en mi vida.
Y finalmente al Instituto Politécnico Nacional (IPN) así como al Consejo Nacional de Ciencia y
Tecnología (CONACyT), instituciones que aportaron el apoyo económico y académico para poder
llevar a cabo este posgrado.
xiii
Concentrador de medidores digitales para sistema de mediciones remotas Índice
Índice
Resumen .............................................................................................................................................................. vii

Abstract ................................................................................................................................................................. ix
Dedicatoria ............................................................................................................................................................ xi
Agradecimientos.................................................................................................................................................. xiii
Índice ....................................................................................................................................................................xv
Lista de figuras.....................................................................................................................................................xix
Lista de tablas .................................................................................................................................................... xxiii
Abreviaturas ....................................................................................................................................................... xxix
Nomenclatura .................................................................................................................................................... xxxi
Capítulo 1: Introducción ....................................................................................................................................... 1
1.1 Generalidades ............................................................................................................................................. 1
1.2 Objetivos de la tesis..................................................................................................................................... 4
1.3 Justificación ............................................................................................................................................... 5
1.4 Estado del arte ............................................................................................................................................ 5
1.5 Alcances ................................................................................................................................................... 10
1.6 Aportaciones............................................................................................................................................. 11
1.7 Estructura de la tesis ................................................................................................................................ 11
Capítulo 2: Marco teórico y propuesta del prototipo de concentrador ................................................................. 13
2.1 Mediciones Eléctricas ............................................................................................................................... 13
2.1.1 Conversión analógica a digital y muestreo de señales ........................................................................ 14
2.1.2 Valor Eficaz o RMS ........................................................................................................................... 15
2.1.3 Potencia Instantánea ......................................................................................................................... 15
2.1.4 Potencia Activa .................................................................................................................................. 16
2.1.5 Potencia Aparente ............................................................................................................................. 16
2.1.6 Potencia Reactiva .............................................................................................................................. 16
2.1.7 Tipos de cargas reactivas ................................................................................................................... 17
2.1.8 Factor de Potencia............................................................................................................................. 18
2.1.9 Energía activa y reactiva ................................................................................................................... 18
2.1.10 Frecuencia ...................................................................................................................................... 19
2.1.11 Distorsión Armónica Total .............................................................................................................. 19
2.1.12 Valores para CFE ............................................................................................................................ 20
2.2 Redes Eléctricas Inteligentes e Infraestructura de Mediciones Avanzadas ............................................... 21
2.2.1 Definición de Red Eléctrica Inteligente ............................................................................................. 22
2.2.2 Retos de una Red Eléctrica Inteligente .............................................................................................. 22
2.2.3 Conformación de una Red Eléctrica Inteligente ................................................................................ 24
2.2.4 Infraestructura de Mediciones Avanzadas (AMI) .............................................................................. 26
2.3 Tecnologías de Internet ............................................................................................................................ 30
2.3.1 Esquema cliente-servidor................................................................................................................... 31
2.3.2 Redes informáticas ............................................................................................................................ 32
2.3.3 Servidores WEB o HTTP ................................................................................................................... 33
xv
2.3.4 Servidores FTP .................................................................................................................................. 35

2.3.5 Bases de datos y Big Data .................................................................................................................. 36
2.4 Propuesta de AMI ..................................................................................................................................... 37
2.4.1 MedidorE ........................................................................................................................................... 38
2.4.2 NodoM ............................................................................................................................................... 41
2.4.3 CMD .................................................................................................................................................. 42
2.4.4 Sistema Administrador ....................................................................................................................... 42
2.4.5 Sistemas de comunicación en la AMI propuesta ................................................................................ 43
Capítulo 3: Integración de Hardware y de los Sistemas de Comunicaciones ....................................................... 45
3.1 Hardware de los Dispositivos de la AMI.................................................................................................... 46
3.1.1 MedidorE ........................................................................................................................................... 46
3.1.2 NodoM ............................................................................................................................................... 48
3.1.3 CMD .................................................................................................................................................. 51
3.1.4 Sistema Administrador ....................................................................................................................... 54
3.2 Sistemas de comunicación dentro de la AMI propuesta ............................................................................ 55
3.2.1 Comunicación MedidorE - NodoM ................................................................................................... 56
3.2.2 Comunicación NodoM - CMD .......................................................................................................... 57
3.2.3 Comunicación CMD – Sistema Administrador.................................................................................. 57
3.3 Diagramas de conexiones de hardware dentro de los dispositivos de la AMI ............................................ 58
3.3.1 Diagrama de conexiones para Medidor............................................................................................... 58
3.3.2 Diagrama de conexiones para NodoM ................................................................................................ 59
3.3.3 Diagrama de conexiones para CMD ................................................................................................... 60
3.3.4 Diagrama de conexiones para Sistema Administrador ........................................................................ 62
Capítulo 4: Descripción del Software Implementado .......................................................................................... 63
4.1 Programa MedidorE ................................................................................................................................. 64
4.1.1 Funciones programadas en el MedidorE ........................................................................................... 66
4.1.2 Interrupciones programadas en el Medidor (Eventos) ....................................................................... 84
4.2 Programa NodoM ..................................................................................................................................... 87
4.2.1 Funciones programadas en el NodoM ............................................................................................... 88
4.2.2 Interrupciones del NodoM (Eventos) ............................................................................................... 110
4.3 Programa datalogger .............................................................................................................................. 114
4.3.1 Descripción de las funciones de datalogger.py ................................................................................. 117
Capítulo 5: Pruebas y resultados obtenidos ....................................................................................................... 127
5.1 Pruebas al MedidorE .............................................................................................................................. 129
5.1.1 Prueba de la instrucción 0x03: leyendo múltiples registros .............................................................. 129
5.1.2 Prueba de la instrucción 0x06: escribiendo un solo registro ............................................................ 130
5.1.3 Prueba de Instrucción 0x10: escribiendo en múltiples registros ....................................................... 131
5.1.4 Prueba de errores MODBUS en el MedidorE .................................................................................. 132
5.2 Pruebas al NodoM .................................................................................................................................. 133
5.2.1 Prueba de la instrucción 0x0F: resetear lista_verificacion .............................................................. 133
5.2.2 Prueba de la instrucción 0x0C: asignar medidor al NodoM ............................................................. 134
5.2.3 Prueba de la instrucción 0x0B: verifica MedidorE por número de esclavo ...................................... 135
5.2.4 Prueba de la instrucción 0x0E: verifica MedidorE por número de serie .......................................... 137
5.2.5 Prueba de la instrucción 0x0A: explorar NodoM ............................................................................. 137
5.2.6 Prueba de la instrucción 0x0D: eliminar un MedidorE del NodoM ................................................. 138
5.2.7 Prueba de la instrucción 0x00: reconfiguración del radio LoRa ...................................................... 139
xvi
5.3 Pruebas a la red LoRa ............................................................................................................................ 140

5.3.1 Pruebas de transmisión de datos ...................................................................................................... 140
5.3.2 Pruebas de rango de transmisión alcanzado .................................................................................... 144
5.4 Pruebas del servidor FTP ....................................................................................................................... 148
5.5 Pruebas del CMD (datalogger) ............................................................................................................... 149
Capítulo 6: Conclusiones y trabajos futuros ..................................................................................................... 157
6.1 Conclusiones .......................................................................................................................................... 157
6.2 Aportaciones........................................................................................................................................... 158
6.3 Trabajos futuros ..................................................................................................................................... 159
Referencias ........................................................................................................................................................ 163
Apéndice A: Sistemas de comunicación y protocolos utilizados ........................................................................... 167
A.1 Redes RS485 ................................................................................................................................................. 167
A.2 Redes LoRa .................................................................................................................................................. 168
A.3 Protocolo de red MODBUS ......................................................................................................................... 170
A.4 Protocolo TCP/IP ......................................................................................................................................... 176
Apéndice B: Componentes de Hardware ............................................................................................................... 179
B.1 Raspberry Pi 2 modelo B ............................................................................................................................. 179
B.2 FRDM-K64F ................................................................................................................................................ 180
B.3 Módulo RF1276T ......................................................................................................................................... 181
B.4 Módulo RS485.............................................................................................................................................. 183
B.5 Módulo DS3231 ........................................................................................................................................... 184
B.6 Módulo Convertidor de niveles lógicos ....................................................................................................... 185
B.7 Enrutador o Router ...................................................................................................................................... 186
B.8 Computadora Personal ................................................................................................................................ 187
B.9 Fuentes, conexiones y accesorios de los radios .......................................................................................... 188
Apéndice C: Configuraciones y Código fuente de MedidorE ................................................................................ 191
C.1 Configuración de los componentes del programa MedidorE con Processor Expert ................................. 191
C.2 Código fuente: main.c ................................................................................................................................ 197
C.3 Código fuente: Events.c ............................................................................................................................. 203
Apéndice D: Configuraciones y Código fuente de NodoM .................................................................................... 205
D.1 Configuración de los componentes del programa NodoM con Processor Expert ..................................... 205
D.2 Código fuente: main.c .............................................................................................................................. 207
D.3 Código fuente: Events.c ............................................................................................................................ 215
Apéndice E: Configuraciones y Código fuente del CMD ...................................................................................... 217
E.1 Configuración de la Raspberry Pi 2 ............................................................................................................ 217
E.2 Código fuente: datalogger.py ................................................................................................................. 237
Apéndice F: Configuraciones de los radios LoRa ................................................................................................. 241
F.1 Herramientas utilizadas ............................................................................................................................... 241
F.2 Configuración de los RF1276T usando una PC ......................................................................................... 241
F.3 Configuración de los RF1276T por mensaje .............................................................................................. 245
xvii
xviii
Concentrador de medidores digitales para sistema de mediciones remotas Lista de Figuras
Lista de figuras
Figura 1.1. AMI, componentes, interacción y comunicación entre ellos ..................................................................................... 3
Figura 2.1. Señal analógica convertida a digital con diferentes frecuencias de muestreo ......................................................... 14
Figura 2.2. Desfase negativo de la corriente y triangulo de potencias de la carga reactiva inductiva ........................................ 17
Figura 2.3. Desfase positivo de la corriente y triangulo de potencias de la carga reactiva capacitiva ....................................... 17
Figura 2.4. Estructura de una Smart Grid ................................................................................................................................. 25
Figura 2.5. Diagrama de una AMI implementada hoy en día.................................................................................................... 30
Figura 2.6. Esquema cliente servidor ....................................................................................................................................... 31
Figura 2.7. Diagrama de la AMI propuesta para este trabajo de tesis ...................................................................................... 38
Figura 2.8. Sistema de medidores en gabinetes aislados ......................................................................................................... 39
Figura 2.9. Diagrama esquemático de medidor tipo 1S monofásico a dos hilos sugerido ......................................................... 39
Figura 2.10. Configuraciones más comunes con medidores tipo 1S para usuarios a baja tensión ............................................. 40
Figura 3.1. Componentes de hardware del MedidorE implementado en esta tesis .................................................................. 47
Figura 3.2. Diagrama de conexiones del MedidorE .................................................................................................................. 48
Figura 3.3. Componentes de hardware del NodoM implementado en esta tesis...................................................................... 50
Figura 3.4. Diagrama de conexiones del NodoM ...................................................................................................................... 51
Figura 3.5. Componentes de hardware del CMD implementado en esta tesis .......................................................................... 53
Figura 3.6. Diagrama esquemático de conexiones del CMD ..................................................................................................... 53
Figura 3.7. Componentes de hardware del Sistema Administrador de la AMI propuesta ......................................................... 55
Figura 3.8. Interacción entre los diferentes protocolos y medios físicos de comunicación de la AMI........................................ 55
Figura 3.9. Diagrama de conexiones de Medidor ..................................................................................................................... 58
Figura 3.10. Diagrama de conexiones de NodoM ..................................................................................................................... 59
Figura 3.11. Diagrama de conexiones de CMD ......................................................................................................................... 61
Figura 3.12. Diagrama de conexiones del Sistema Administrador ............................................................................................ 62
Figura 4.1. Ejemplo del archivo lista_medidores.txt. ............................................................................................................. 115

Figura 4.2. Ejemplo de un archivo de datalogger del medidor “m001XYZ000” y con fecha de marzo del 2016:
m001XYZ000_3_2016.txt. ..................................................................................................................................................... 116
Figura 5.1. Terminal SSCOM32E utilizada mostrando tanto el mensaje de petición enviado al medidor, como el mensaje de
respuesta generado por el medidor ...................................................................................................................................... 128
Figura 5.2. Tarjeta FRDM-KF64 simulando un medidor de pruebas siendo activado. ............................................................. 130
Figura 5.3. Tres radios conectados con sus adaptadores USB en la misma PC ........................................................................ 141
Figura 5.4. Al desconectar el pin EN, el RF1276T entrará en modo CAD, esto solo se utilizará en los módulos Nodo .............. 141
xix
Figura 5.5. Enviando “00 02 33 44 55 66 77 88” desde el módulo Central (en COM5) al Nodo 2............................................. 141
Figura 5.6. Recibiendo “33 44 55 66 77 88” con el Nodo 2 en el COM7 .................................................................................. 142
Figura 5.7. El Nodo 3 en el COM6 no deberá recibir ningún dato ........................................................................................... 142
Figura 5.8. Enviando “22 22 22 22 22 22 22 22 02” al Nodo 3 desde el módulo Central en el COM5 ....................................... 142
Figura 5.9. Recibiendo “22 22 22 22 22 22 22 22 02” con el Nodo 3 en el COM6 .................................................................... 143
Figura 5.10. El Nodo 2 en el COM6 no debe recibir nada en esta ocasión .............................................................................. 143
Figura 5.11. Mapa de donde se realizaron las pruebas de alcance con los radios LoRa .......................................................... 145
Figura 5.12. Vista aérea real de la zona de pruebas obtenida desde www.google.com.mx/maps ......................................... 145
Figura 5.13. Alcance obtenido con antena de baja ganancia y mucha interferencia: 248m ................................................... 146
Figura 5.14. Alcance obtenido con antena de alta ganancia y mucha interferencia: 351m .................................................... 146
Figura 5.15. Alcance obtenido con antena de alta ganancia y mucha interferencia: 385m .................................................... 147
Figura 5.16. Alcance obtenido con antena de alta ganancia y poca interferencia: 491.6m .................................................... 147
Figura 5.17. Vista del panel superior de “FileZilla” donde se ingresan servidor, usuario y contraseña .................................. 148
Figura 5.18. Vista de “FileZilla” mostrando las ventanas para compartir archivos entre PC y servidor FTP ............................ 149
Figura 5.19. Ejecución de datalogger.py desde “LXTerminal” ............................................................................................... 150
Figura 5.20. “LXTerminal” mostrando los datos obtenidos después de comunicarse con el MedidorE “m001XYZ000” ......... 150
Figura 5.21. Gráfica de KWh medidos en un día (1 de Enero del 2016), muestras cada 10 minutos ....................................... 151
Figura 5.22. Gráfica de KWh medidos durante un mes (Enero del 2016), muestras cada 10 minutos .................................... 151
Figura 5.23. Energía activa medida cada hora del 1 de enero del 2016 ................................................................................. 152
Figura 5.24. Energía activa medida cada día del mes de Enero del 2016 ............................................................................... 152
Figura 5.25. Gráfica de KVArh medidos en un día (1 de Enero del 2016), muestras cada 10 minutos .................................... 153
Figura 5.26. Gráfica de KVArh medidos en un mes (Enero del 2016), muestras cada 10 minutos .......................................... 153
Figura 5.27. Energía reactiva medida cada hora del 1 de enero del 2016 .............................................................................. 154
Figura 5.28. Energía reactiva medida cada día del mes de Enero del 2016 ............................................................................ 154
Figura 5.29. Gráfica de THD máximo entre cada medición durante un día (1 Enero del 2016), muestras cada 10 minutos ... 155
Figura 5.30. Gráfica de THD máximo entre cada medición durante un mes (Enero del 2016), muestras cada 10 minutos ..... 155
Figura 5.31. THD máximo detectado cada hora del 1 de Enero del 2016 ............................................................................... 156
Figura 5.32. THD máximo detectado cada día de Enero del 2016 .......................................................................................... 156
Figura A.1. Diagrama de una red RS485 a dos hilos .............................................................................................................. 167
Figura A.2. Topología de red LoRa ......................................................................................................................................... 169
Figura A.3. Formato de un mensaje MODBUS tipo RTU ......................................................................................................... 169
Figura B.1. Detalle de los puertos GPIO de la Raspberry Pi 2 ................................................................................................. 179

Figura B.2. Vista general de la Raspberry Pi 2 modelo B y sus puertos................................................................................... 180
Figura B.3. Detalle de la FRDM-K64F, sus periféricos y sus puertos ....................................................................................... 181
xx
Figura B.4. Detalle del RF1276T, dimensiones y pines entrada-salida .................................................................................... 182
Figura B.5. Diagrama interno de un MAX485 así como sus terminales ................................................................................... 183
Figura B.6. Vista general del módulo RS485 y sus terminales así como el circuito esquemático ............................................. 183
Figura B.7. Vista general del módulo DS3231 y sus terminales así como el circuito esquemático ........................................... 185
Figura B.8. Convertidor de niveles lógicos físicamente, sus terminales y su circuito .............................................................. 186
Figura B.9. Router HG8245H marca HUAWEI ......................................................................................................................... 187
Figura B.10. Fuentes de alimentación a 5Vcc con salida USB usadas en esta AMI .................................................................. 188
Figura B.11. Conexiones utilizadas entre los diferentes periféricos y dispositivos de la AMI .................................................. 189
Figura B.12. Adaptador USB-UART con el circuito integrado PL2303HXD ............................................................................... 189
Figura B.13. Antenas con entrada SMA utilizadas con los radios LoRa RF1276T ..................................................................... 190
Figura C.1. Para seleccionar el microcontrolador adecuado en la ventana “Components Inspector”, en la casilla “CPU type”
buscar y seleccionar al MK64FM0VLL12 ................................................................................................................................ 192
Figura C.2. Para seleccionar la memoria de trabajo se da clic izquierdo en FLASH y se selecciona la opción “Select
Configuration as Active” ....................................................................................................................................................... 192
Figura E.1. Pantalla de entorno gráfico de Raspbian en la Raspberry Pi 2 .............................................................................. 218

Figura E.2. Vista de “LXTerminal”, que se utilizará para los pasos siguientes ......................................................................... 219
Figura E.3. Opciones de Raspberry Pi Software Configuration Tool ........................................................................................ 219
Figura E.4. Opciones dentro de Internationalisation Options ................................................................................................. 220
Figura E.5. Opción de idioma que viene por defecto .............................................................................................................. 220
Figura E.6. De nuevo seleccionar la opción es_MX.UTF-8 UTF-8............................................................................................. 220
Figura E.7. Opciones de continente dentro de Configuring tzdata.......................................................................................... 221
Figura E.8. Opciones de ciudad dentro de Configuración de tzdata ........................................................................................ 221
Figura E.9. Se creará un nuevo archivo dentro de la carpeta “Home” .................................................................................... 221
Figura E.10. Líneas necesarias para configurar al teclado en español ..................................................................................... 222
Figura E.11. Esta es la dirección IP del router o puerta de enlace ........................................................................................... 223
Figura E.12. Accediendo la interfaz del router, en este caso se trata de un Huawei modelo HG245H ..................................... 223
Figura E.13. Lista de dispositivos conectados al router, se puede ver entre ellos a la Raspberry Pi ........................................ 224
Figura E.14. Es obligatorio seleccionar esta opción ................................................................................................................ 227
Figura E.15. Pantalla inicial de TightVNC, donde se teclea la dirección IP de la Raspberry Pi .................................................. 227
Figura E.16. Pantalla de autentificación para ingresar a la Raspberry Pi................................................................................. 228
Figura E.17. Escritorio remoto de la Raspberry Pi corriendo desde una PC con Windows gracias a TightVNC ......................... 228
Figura E.18. Archivo modules ya con los nuevos módulos agregados ..................................................................................... 230
Figura E.19. Se muestran activos los módulos i2c .................................................................................................................. 230
Figura E.20. Tabla de posiciones I2C ocupadas por algún dispositivo ..................................................................................... 231
Figura E.21. Ahora se muestra UU en la posición 0x86........................................................................................................... 231
xxi
Figura E.22. Archivo rc.local con las 2 nuevas líneas agregadas ............................................................................................. 232
Figura E.23. Archivo inittab con la última línea comentada ................................................................................................... 233
Figura E.24. Terminal de Minicom donde se pueden teclear valores ASCII con el teclado y si todo está bien se deberán
visualizar en la misma pantalla ............................................................................................................................................. 234
Figura E.25. Archivo shells en el que se agregó /bin/FTP ....................................................................................................... 235
Figura F.1.. Adaptador USB-UART con el circuito integrado CP2102 ...................................................................................... 242
Figura F.2. Adaptador USB-UART con el circuito integrado PL2303HXD y conector especial para radios de appconwireless .. 242
Figura F.3. En el administrador de dispositivos de Windows deberá aparecer el adaptador como un puerto COM................ 242
Figura F.4. Conexión del RF1276T con el convertidor USB-UART para programarlo ............................................................... 243
Figura F.5. Herramienta RF Tool utilizada para configurar los radios RF1276T ....................................................................... 243
Figura F.6. Si todo está bien nos mostrará “Opened” ............................................................................................................ 244
Figura F.7. Si todo va bien mostrará “Successful” .................................................................................................................. 245
Figura F.8. Configuración de un RF1276T usando comandos enviados con la terminal SSCOM3.2 ......................................... 248
xxii
Concentrador de medidores digitales para sistema de mediciones remotas Lista de tablas
Lista de tablas
Tabla 2.1. Diferencias entre Internet, Intranet y Extranet ........................................................................................................ 33
Tabla 3.1. Medios físicos de comunicación y protocolos entre las diferentes etapas de la AMI ................................................ 55
Tabla 3.2. Conexiones entre la FRDM-K64F y el módulo RS485 ................................................................................................ 58
Tabla 3.3. Conexiones entre la FRDM-K64F y el Convertidor de niveles lógicos ....................................................................... 60
Tabla 3.4. Conexiones entre la FRDM-K64F y el Módulo RS485 ............................................................................................... 60
Tabla 3.5. Conexiones entre el Convertidor de niveles lógicos y el RF1276T ............................................................................ 60
Tabla 3.6. Conexiones entre la Raspberry Pi 2 y el Módulo DS3231 ......................................................................................... 61
Tabla 3.7. Conexiones entre la Raspberry Pi 2 y el Convertidor de niveles lógicos ................................................................... 62
Tabla 3.8. Conexiones entre el Convertidor de niveles lógicos y el RF1276T ............................................................................ 62
Tabla 4.1. Variable Registro donde se leerán y/o escribirán datos usando los comando MODBUS........................................... 65
Tabla 4.2. Diagrama de flujo y explicación de f_main .............................................................................................................. 68
Tabla 4.3. Variables locales usadas por f_reset ....................................................................................................................... 68
Tabla 4.4. Diagrama de flujo de f_reset ................................................................................................................................... 69
Tabla 4.5. Variables globales y locales usadas por f_inicia_medidor ....................................................................................... 69
Tabla 4.6. Diagrama de flujo de f_inicia_medidor ................................................................................................................... 70
Tabla 4.7. Variables globales y locales usadas por f_medidor ................................................................................................. 74
Tabla 4.8. Diagrama de flujo de f_medidor ............................................................................................................................. 74
Tabla 4.9. Variables globales usadas por f_MODBUS .............................................................................................................. 77
Tabla 4.10. Diagrama de flujo de f_MODBUS .......................................................................................................................... 77
Tabla 4.11. Variables globales y locales usadas por f_analizar_mensaje ................................................................................. 78
Tabla 4.12. Diagrama de flujo f_analizar_mensaje ................................................................................................................. 78
Tabla 4.13. Variables globales y locales usadas por f_calcular_crc .......................................................................................... 79
Tabla 4.14. Diagrama de flujo de f_calcular_crc ...................................................................................................................... 79
Tabla 4.15. Variables globales y locales usadas por f_lee_multi .............................................................................................. 80
Tabla 4.16. Diagrama de flujo de f_lee_multi ......................................................................................................................... 80
Tabla 4.17. Variables globales y locales usadas por f_escribe_uno .......................................................................................... 81
Tabla 4.18. Diagrama de flujo de f_escribe_uno ..................................................................................................................... 81
Tabla 4.19. Variables globales y locales usadas por f_escribe_multi ....................................................................................... 82
Tabla 4.20. Diagrama de flujo de f_escribe_multi ................................................................................................................... 82
Tabla 4.21. Variables globales y locales usadas por f_formar_replica ..................................................................................... 83
Tabla 4.22. Diagrama de flujo de f_formar_replica ................................................................................................................. 83
Tabla 4.23. Variables globales y locales usadas por f_enviar_replica ...................................................................................... 84
xxiii
Tabla 4.24. Diagrama de flujo de f_enviar_replica ................................................................................................................. 84

Tabla 4.25. Variables globales y locales usadas por RS485_OnRxChar ..................................................................................... 85
Tabla 4.26. Diagrama de flujo de RS485_OnRxChar................................................................................................................. 85
Tabla 4.27. Variables globales usadas por TI1_OnInterrupt ..................................................................................................... 85
Tabla 4.28. Diagrama de flujo de TI1_OnInterrupt .................................................................................................................. 86
Tabla 4.29. Variables globales usadas por RS485_OnTxChar ................................................................................................... 86
Tabla 4.30. Diagrama de flujo de RS485_OnTxChar ................................................................................................................. 86
Tabla 4.31. Variable lista_verificacion, donde se almacenan los números de serie de los medidores agregados en el NodoM 88
Tabla 4.32. Diagrama de flujo de main .................................................................................................................................... 92
Tabla 4.33. Variables globales y locales usadas por f_inicia_nodoM........................................................................................ 92
Tabla 4.34. Diagrama de flujo de f_inicia_nodoM .................................................................................................................. 92
Tabla 4.35. Variables globales y locales usadas por f_checa_lista ........................................................................................... 93
Tabla 4.36. Diagrama de flujo de f_checa_lista ....................................................................................................................... 93
Tabla 4.37. Variables globales y locales usadas por f_checa_medidor ..................................................................................... 94
Tabla 4.38. Diagrama de flujo de f_checa_medidor ................................................................................................................ 94
Tabla 4.39. Variables globales y locales usadas por f_conecta_medidor .................................................................................. 95
Tabla 4.40. Diagrama de flujo de f_conecta_medidor ............................................................................................................. 95
Tabla 4.41. Variables globales y locales usadas por f_nvomsj_CMD ........................................................................................ 96
Tabla 4.42. Diagrama de flujo de f_nvomsj_CMD .................................................................................................................... 97
Tabla 4.43. Variables globales y locales usadas por f_analizar_mensaje ................................................................................. 97
Tabla 4.44. Diagrama de flujo de f_analizar_mensaje ............................................................................................................ 98
Tabla 4.45. Variables globales y locales usadas por f_checar_numdisp ................................................................................... 98
Tabla 4.46. Diagrama de flujo de f_checar_numdisp ............................................................................................................... 99
Tabla 4.47. Variables globales y locales usadas por f_checar_instruc ...................................................................................... 99
Tabla 4.48. Diagrama de flujo de f_checar_instruc ............................................................................................................... 100
Tabla 4.49. Variables globales y locales usadas por f_nodo_0x00 .......................................................................................... 101
Tabla 4.50. Diagrama de flujo de f_nodo_0x00 ..................................................................................................................... 101
Tabla 4.51. Variables globales y locales usadas por f_nodo_0x0A ......................................................................................... 101
Tabla 4.52. Diagrama de flujo de f_nodo_0x0A .................................................................................................................... 102
Tabla 4.53. Variables globales y locales usadas por f_nodo_0x0B ......................................................................................... 103
Tabla 4.54. Diagrama de flujo de f_nodo_0x0B .................................................................................................................... 103
Tabla 4.55. Variables globales y locales usadas por f_nodo_0x0C.......................................................................................... 103
Tabla 4.56. Diagrama de flujo de f_nodo_0x0C ..................................................................................................................... 104
Tabla 4.57. Variables globales y locales usadas por f_nodo_0x0D ......................................................................................... 105
Tabla 4.58. Diagrama de flujo de f_nodo_0x0D .................................................................................................................... 105
Tabla 4.59. Variables globales y locales usadas por f_nodo_0x0E .......................................................................................... 106
xxiv
Tabla 4.60. Diagrama de flujo de f_nodo_0x0E ..................................................................................................................... 106

Tabla 4.61. Variables globales y locales usadas por f_nodo_0x0F .......................................................................................... 107
Tabla 4.62. Diagrama de flujo de f_nodo_0x0F ..................................................................................................................... 107
Tabla 4.63. Variables globales y locales usadas por f_instruc_MODBUS ................................................................................ 108
Tabla 4.64. Diagrama de flujo de f_instruc_MODBUS ........................................................................................................... 108
Tabla 4.65. Variables globales y locales usadas por f_formar_replica .................................................................................... 109
Tabla 4.66. Diagrama de flujo de f_formar_replica ............................................................................................................... 109
Tabla 4.67. Variables globales y locales usadas por RS485_OnRxChar ................................................................................... 110
Tabla 4.68. Diagrama de flujo de RS485_OnRxChar ............................................................................................................... 110
Tabla 4.69. Variables globales y locales usadas por RADIO_OnRxChar................................................................................... 111
Tabla 4.70. Diagrama de flujo de RADIO_OnRxChar .............................................................................................................. 111
Tabla 4.71. Variables globales usadas por TI1_OnInterrupt ................................................................................................... 112
Tabla 4.72. Diagrama de flujo de TI1_OnInterrupt ................................................................................................................. 112
Tabla 4.73. Variables globales usadas por RS485_OnTxChar .................................................................................................. 112
Tabla 4.74. Diagrama de flujo de RS485_OnTxChar ............................................................................................................... 113
Tabla 4.75. Variables globales usadas por RADIO_OnTxChar ................................................................................................. 113
Tabla 4.76. Diagrama de flujo RADIO_OnTxChar ................................................................................................................... 113
Tabla 4.77. Librerías (color rosa) y variables globales utilizadas por el programa principal .................................................... 118
Tabla 4.78. Diagrama de flujo el programa principal ............................................................................................................. 118
Tabla 4.79. Variables globales y locales utilizadas por la función datalogger ........................................................................ 119
Tabla 4.80. Diagrama de flujo de la función datalogger ........................................................................................................ 119
Tabla 4.81. Variables globales y locales utilizadas por la función ver_lista_meds.................................................................. 120
Tabla 4.82. Diagrama de flujo de la función ver_lista_meds ................................................................................................. 120
Tabla 4.83. Variables globales y locales utilizadas por la función formar_msjs...................................................................... 121
Tabla 4.84. Diagrama de flujo de la función formar_msjs ..................................................................................................... 121
Tabla 4.85. Variables locales utilizadas por la función CRCMODBUS ..................................................................................... 121
Tabla 4.86. Diagrama de flujo de la función CRCMODBUS .................................................................................................... 122
Tabla 4.87. Variables locales utilizadas por la función leer_medidor ..................................................................................... 122
Tabla 4.88. Diagrama de flujo de la función leer_medidor .................................................................................................... 123
Tabla 4.89. Variables locales utilizadas por la función logear................................................................................................ 125
Tabla 4.90. Diagrama de flujo de la función logear ............................................................................................................... 125
Tabla 5.1. Ejemplo de petición con la instrucción 0x03 ......................................................................................................... 129

Tabla 5.2. Respuesta al mensaje de la tabla 5.1 .................................................................................................................... 129
Tabla 5.3. Mensaje de petición con la instrucción 0x06 para activar al MedidorE 255 ........................................................... 130
Tabla 5.4. Respuesta al mensaje de la tabla 5.3 .................................................................................................................... 131
xxv
Tabla 5.5. Mensaje para desactivar al MedidorE .................................................................................................................. 131

Tabla 5.9. Mensaje de petición con la instrucción 0x10 para asignar tiempo de muestreo de mediciones ............................ 131
Tabla 5.10. Respuesta en caso OK ........................................................................................................................................ 132
Tabla 5.11. Errores MODBUS durante la comunicación NodoM-Medidor .............................................................................. 132
Tabla 5.12. Respuesta en caso OK ........................................................................................................................................ 133
Tabla 5.13. Mensaje para borrar todos los medidores del NodoM 0x0002 ........................................................................... 134
Tabla 5.14. Mensaje de respuesta OK .................................................................................................................................. 134
Tabla 5.15. Mensaje para agregar el MedidorE m001XYZ000, esclavo 255 en el NodoM 0x0002 .......................................... 135
Tabla 5.16. Mensaje de respuesta OK del NodoM ................................................................................................................ 135
Tabla 5.17. Mensaje para verificar el número de serie del MedidorE esclavo 255 en el NodoM 0x0002 ............................... 135
Tabla 5.18. Mensaje de respuesta del NodoM, entregando el número de serie del MedidorE solicitado .............................. 136
Tabla 5.19. Mensaje para solicitar el número de serie del NodoM 0x0002 ........................................................................... 136
Tabla 5.20. Mensaje de respuesta del NodoM, entregando su número de serie ................................................................... 136
Tabla 5.21. Mensaje para solicitar el número de serie del MedidorE 100, si es que existe .................................................... 136
Tabla 5.22. Mensaje de respuesta del NodoM indicando que no hay MedidorE en la posición 100 ...................................... 136
Tabla 5.23. Mensaje para verificar el número de esclavo del MedidorE “m001XYZ000” en el NodoM 0x0002 ...................... 137
Tabla 5.24. Mensaje respuesta de parte del NodoM 0x0002 ................................................................................................ 137
Tabla 5.25. Mensaje de respuesta del NodoM al no encontrar el número de serie ............................................................... 137
Tabla 5.26. Mensaje para ver la lista_verificacion del NodoM 0x0002 .................................................................................. 138
Tabla 5.27. Mensaje de respuesta del NodoM mostrando el contenido en su lista_verificacion ........................................... 138
Tabla 5.28. Mensaje para dar de baja al MedidorE 255, número de serie “m001XYZ000”, del NodoM 0x0002 ..................... 139
Tabla 5.29. Mensaje de respuesta OK del NodoM ................................................................................................................ 139
Tabla 5.30. Mensaje para configurar el radio LoRa del NodoM 0x0002 ................................................................................ 139
Tabla 5.31. Mensaje erróneo para configurar el radio LoRa del NodoM 0x0002 ................................................................... 140
Tabla 5.32. Mensaje de error al tratar de reconfigurar el radio LoRa del NodoM 0x0002 ..................................................... 140
Tabla 5.33. Alcance obtenido según las condiciones de la prueba ......................................................................................... 147
Tabla A.1. Registros dentro del medidor para leer y/o escribir usando los comando MODBUS ............................................. 173
Tabla A.2. lista_verificacion, que almacena los números de serie de los medidores agregados en el NodoM ....................... 175
Tabla B.1. Descripción de los pines del RF1276T ................................................................................................................... 182

Tabla B.2. Descripción de los pines del Módulo RS485 .......................................................................................................... 184
Tabla B.3. Descripción de los pines del Módulo DS3231 ........................................................................................................ 185
Tabla B.4. Descripción de los pines del Módulo DS3231 ........................................................................................................ 186
Tabla C.1. Configuración básica de ENEABLE para controlar el MAX485 ................................................................................ 193
xxvi
Tabla C.2. Configuraciones básicas del puerto serial .............................................................................................................. 194

Tabla C.3. Configuración básica de ENEABLE para controlar el MAX485................................................................................. 194
Tabla C.4. Configuración básica del temporizador ................................................................................................................. 195
Tabla C.5. Configuración del LED rojo .................................................................................................................................... 195
Tabla C.6. Configuración de componente de Memoria FLASH ................................................................................................ 196
Tabla D.1. Configuraciones básicas del puerto serial para el RS485 del NodoM ..................................................................... 206
Tabla E.1. Líneas necesarias para hacer al programa VNC ejecutable desde el arranque del CMD ......................................... 226
Tabla F.1. Parámetros a configurar en los radios RF1276T ..................................................................................................... 244

Tabla F.2. Formato del mensaje de configuración para el RF1276T ........................................................................................ 245
Tabla F.4. Y ........................................................................................................................................................................... 246
Tabla F.3. X ........................................................................................................................................................................... 246
Tabla F.5. Bauds .................................................................................................................................................................... 246
Tabla F.6. Paridad ................................................................................................................................................................. 246
Tabla F.7. Frecuencia: F1,F2,F3 ................................................................................................................................................ 246
Tabla F.8. RF_Factor .............................................................................................................................................................. 246
Tabla F.9. Modo .................................................................................................................................................................... 246
Tabla F.10. RF_BW ................................................................................................................................................................ 246
Tabla F.11. ID1, ID2 ............................................................................................................................................................... 246
Tabla F.12. NET ..................................................................................................................................................................... 246
Tabla F.13. RF_Power ............................................................................................................................................................ 246
xxvii
xxviii
Concentrador de medidores digitales para sistema de mediciones remotas Abreviaturas
Abreviaturas
AAM “Advanced Asset Management” (Gestión de Activos Avanzada).
ADC “Analog Digital Converter” (Convertidor Analógico Digital)
ADO “Advanced Distribution Operations” (Operaciones de distribución Avanzadas)
AMI “Advanced Metering Infrastructure” (Infraestructura de Mediciones Avanzadas).
AMR “Automatic Meter Reading” (Lectura de Mediciones Autamatizada)
ATO “Advanced Transmission Operations” (Operaciones de Transmisión Avanzada)
CAN “Controller Area Network” (Red de Area Controlada)
CFE Comisión Federal de Electricidad
CRC “Cyclic Redundancy Check” (Checador de Redundancia Cíclica)
CPU “Central Processing Unit” (Unidad de Procesamiento Central)
DFT “Discrete Fourier Transform” (Transformada Discreta de Fourier)
DNP3 “Distributed Network Protocol, ver. 3” (Protocolo de red distribuida versión 3)
FFT “Fast Fourier transform” (Transformada Rápida de Fourier)
FTP “File Transfer Protocol” (Protocolo de Transferencia de Archivos)
GPIO “General Purpose Input/Output” (Entradas/Salidas de Propósito Gneral)
GPRS “General Packet Radio Service” (Servicio General de Paquetes vía Radio)
HAN “Home Area Network” (Red de Area Doméstica)
HTML “Hyper Text Markup Language” (Lenguaje de Marcas de Hipertexto)
HTTP “Hyper Text Transfer Protocol” (Protocolo de Transferencia de Hipertexto)
I2C ó IIC “Inter-Integrated Circuit” (Sin traducción)
IEEE “Institute of Electrical and Electronics Engineers” (Instituto de Ingenieros en
Electricidad y Electrónica)
IHD “In Home Display” (Pantalla en el Hogar)
IP “Internet Protocol” (Protocolo de Internet)
ISO “International Organization for Standardization” (Organización Internacional de
Normalización)
LAN “Local Area Network” (Red de Area Local)
LoRa “Long Range” (Largo Alcance)
MAN “Metropollitan Area Network” (Red de Área Metropolitana)
MCU “MicroController Unit” (Microcontrolador)
Mi-Fi Hace referencia a “Movil Wi-Fi”
NAN “Neighbour Area Network” (Red de Area Vecina)
P2P “Peer to Peer” (Punto a Punto)
PC “Personal Computer” (Computadora Personal)
PLC “Power Line Carrier” (Portadora en Linea de Potencia)
PROFIBUS derivada de “PROcess FIeld BUS” (Bus de proceso de Planta)
RAM “Random Access Memory” (Memoria de Acceso Aleatorio)
RMS “Root Mean Square” (Raiz Cuadrada Media)
xxix
Concentrador de medidores digitales para sistema de mediciones remotas Abreviaturas
SCADA “Supervisory Control And Data Acquisition” (Control de supervisión y

Adquisición de Datos)
SMA “Sub-Miniature version A” (Sub Miniatura versión A)
TCP “Transfer Control Protocol” (Protocolo de Control de Transferencia)
THD “Total Harmonic Distortion” (Distorsión Armónica Total)
TWACS “Two-Way Automatic Communications System” (Sistema de Comunicaciones
Automatizadas de Doble Camino)
UART “Universal Asynchronous Receiver-Transmitter” (Receptor-Transmisor
Asíncrono Universal
UPS “Uninterruptible Power Supply” (Fuente de Alimentación Ininterrumpida)
UTP “Unshielded Twisted Pair” (Par Trenzado no Blindado)
VNC “Virtual Network Computing” (Computación de Red Virtual)
WAN “Wide Area Network” (Red de Area Amplia)
Wi-Fi Nombre comercial para el sistema de conexión de datos inalámbricos del estándar
IEEE 802.11
WiMAX “Worldwide Interoperability for Microwave Access” (Interoperabilidad Mundial
para Acceso por Microondas)
xxx
Concentrador de medidores digitales para sistema de mediciones remotas Nomenclatura
Nomenclatura
X(t)rms Valor RMS de señal continua en el dominio del tiempo

X(n)rms Valor RMS de señal discreta en el dominio del tiempo
x(n) señal continua en el dominio del tiempo
x(t) señal discreta en el dominio del tiempo
T Periodo o duración de un ciclo
N Número de muestras en un periodo
t Ttiempo
ts Tiempo en segundos
tmin Tiempo en minutos
th Tiempo en horas
n Índices de señales discretas
p(t) Potencia instantánea
v(t) Voltaje instantáneo
i(t) Corriente instantánea
vrms(t) Voltaje RMS instantáneo
irms(t) Corriente RMS instantánea
P Potencia activa
S Potencia aparente
Q Potencia reactiva
𝛷 Ángulo de desfase entre voltaje y corriente
𝛷𝑣 Ángulo de desfase del voltaje
𝛷𝑖 Ángulo de desfase del corriente
fp Factor de potencia
EP Energía activa
EQ Energía reactiva
THD Distorsión armónica total
xxxi
Concentrador de medidores digitales para sistema de mediciones remotas Nomenclatura
xxxii
Concentrador de medidores digitales para sistema de mediciones remotas Capítulo 1
Capítulo 1: Introducción
1.1 Generalidades
Con el paso de los años las investigaciones se han centrado en la mejora de los sistemas eléctricos
de potencia y en la implementación de fuentes de energía renovables. Con el fin de utilizar mejor
la infraestructura eléctrica que ya se tiene una de las áreas de más alto impacto para los años
próximos serán las Redes Eléctricas Inteligentes o comúnmente denominadas Smart Grids [1].
Una Red Eléctrica Inteligente es tan grande y compleja como el mismo sistema eléctrico de
potencia, conformada por diferentes etapas. La primera etapa que relaciona a la Red Eléctrica
Inteligente con la red eléctrica actual es la denominada AMI. AMI es el acrónimo en inglés de
Advanced Metering Infrastructure, o en infraestructura de mediciones avanzadas en español.
Expresado de forma muy breve una AMI es la encargada de obtener todos los datos de consumo
eléctrico, gracias a estos datos el resto de la Red Eléctrica Inteligente puede tomar decisiones
primero para generar justo la energía que se requiere adaptándose y anticipándose al
comportamiento variante que presentan la demanda, hecho esto una Red Eléctrica Inteligente podrá
entonces realizar otras tareas como son implementar energías renovables de forma eficiente,
implementar la conexión de microredes de generación, anticiparse a fallas, etc. [2].
1
Tanto en México como en otros países las AMI que han sido implementadas son muy diferentes
unas de otras. La variedad de sistemas de comunicación, de dispositivos inteligentes e incluso las
etapas y procesos de interacción entre unos y otros han sido elección de cada fabricante.
Comunicaciones mediante sistemas PLC a baja tensión o a media tensión (TWACS), enlaces
mediante redes inalámbricas tipo mesh (malla) o punto a punto (LoRa por ejemplo),
comunicaciones basadas en sistemas GPRS (redes celulares) e incluso Wi-Fi, implementación de
redes Ethernet, fibra óptica, satelital, etc. La variedad y combinaciones son muy amplias y hasta
ahora no hay un estándar que obligue a decidir por una tecnología u otra [3].
Este trabajo de tesis ha sido desarrollado con la finalidad de crear un prototipo denominado
concentrador de medidores digitales el cual funge como corazón de una AMI. Para poder hacer una
implementación práctica y funcional en esta tesis será necesario no solo desarrollar al concentrador
sino también involucrarse con el resto de componentes que conforman a una AMI.
Para realizar la propuesta de esta AMI es necesario identificar los componentes que se usarán, así
como los medios de comunicación que unirán a unos con otros [4]. En la propuesta de esta tesis
resalta el uso de redes punto a punto como medio de comunicación entre el concentrador y nodos
intermedios, los cuales a su vez son los encargados de concentrar a varios medidores [5]. Los
componentes básicos y necesarios para una AMI de este tipo pueden ser enlistados en los siguientes
puntos:
 Medidor: Obtiene las mediciones eléctricas.

 Nodo: Nodo de red, se trata de un dispositivo que sirve como primer concentrador o punto
intermediario entre un grupo de medidores y el resto de la red AMI, en algunos casos es un
dispositivo adicional mientras que en otros se trata de otro medidor que también se
comporta como nodo.
 Concentrador: Concentrador principal que controla y monitorea a uno o más Nodos en un
área geográfica considerable, en el rango de cientos de metros o incluso kilómetros.
 Sistema Administrador: Control de todos los Concentradores existentes en la AMI por
medio de la red (o mejor dicho intranet) de la compañía administradora (por ejemplo CFE).
 Pantalla de Usuario es la interfaz con la que tiene interacción directa el usuario final, o
por lo menos mediante la cual puede tener acceso de forma visual a su consumo de energía
eléctrica. En la propuesta de esta AMI no se incluyó, se considera un dispositivo adicional,
el cual puede ser vinculado posteriormente con el medidor, con el concentrador o
directamente con los servidores web del sistema administrador.
En la figura 1.1 se muestra una AMI como a la que se pretende llegar en este trabajo de tesis para
poder implementar al concentrador, mostrando los diferentes componentes, la relación entre unos
y otros y el medio de comunicación para intercomunicarlos.
2
Figura 1.1. AMI, componentes, interacción y comunicación entre ellos
3
1.2 Objetivos de la tesis
Objetivo general:
Implementar un prototipo de dispositivo denominado Concentrador de Medidores Digitales

llamado CMD (llamado así en este trabajo por la abreviatura de sus iniciales) el cual será el
dispositivo central dentro de una AMI.
Objetivos particulares:
 Crear un prototipo de medidor emulado que actuará como medidor digital de tipo gabinete,
es decir que genere mediciones ficticias de forma análoga a un medidor inteligente real con
el fin de probar al CMD dentro de una AMI.
 Crear un prototipo de dispositivo intermedio entre el CMD y los medidores digitales con
el fin de concentrar a varios en un solo punto, este dispositivo puede ser definido como un
nodo viéndolo como un punto intermedio dentro de una red.
 Hacer que el CMD tenga la capacidad de interactuar con los otros dispositivos de la AMI
sin la necesidad de intervención humana.
 Concentrar los datos de mediciones y configuraciones de todos los medidores inteligentes
de la AMI con este CMD.
 Programar en el CMD rutinas de monitoreo y adquisición de datos que corran de forma
permanente, haciendo que actúe como un datalogger.
 Hacer que el CMD sea un “Gateway”, es decir un medio físico capaz de unir dos redes
diferentes, por un lado una red inalámbrica punto a punto para comunicarse con los
medidores inteligentes y por otro lado una red TCP/IP para comunicarse con el sistema
administrador.
 Hacer que el CMD funcione como un servidor informático.
 Implementar los sistemas de comunicaciones alámbricos e inalámbricos necesarios para
comunicar a los diferentes dispositivos de la AMI.
 Crear una interfaz hombre-máquina que se comporte como el sistema administrador de la
AMI, es decir por medio del cual una persona tendrá acceso y control remoto y en tiempo
real del CMD y por lo tanto de la AMI.
4
1.3 Justificación
Este trabajo nació del resultado de una investigación de campo de la red AMI implementada en
Acapulco, por la CFE, que se realizó en el año 2015, en este trabajo se hizo un análisis de las fallas,
se realizó un trabajo de ingeniería a la inversa y se concluyó que la red presentaba fallas frecuentes
de comunicación en el concentrador.
Debido a que la CFE adquirió cajas negras desconociendo totalmente la tecnología y los protocolos
de comunicación, se les hizo la propuesta de diseñar una AMI partiendo de cero, y esta es la
justificación principal de este trabajo.
La justificación para esta tesis radica en documentar el diseño e implementación de un dispositivo

inteligente que trabaje como concentrador, el cual tomará constantemente lectura de un conjunto
de medidores inteligentes y pondrá a disposición de un administrador final dichos datos por medio
de una red informática TCP/IP.
1.4 Estado del arte
La implementación de sistemas AMI para la complementación de Redes Eléctricas Inteligentes ha

sido una nueva tendencia alrededor del mundo, comenzando primero con los sistemas AMR
(Automatic Meter Reading o lectura de medición automática en español) en la década de los
ochentas los cuales permitían la lectura remota de los medidores digitales con fines de facturación
más sin embargo no permitían controlar su corte o reconexión debido a que utilizaban sistemas de
comunicaciones unidireccionales. [6]
Años más tarde con las mejoras y avances en las tecnologías de telecomunicaciones y electrónica
se pudieron implementar comunicaciones bidireccionales que permitirían tanto el monitoreo como
el control a distancia de los medidores permitiendo hacer una transición de sistemas AMR a
sistemas AMI. [6]
Desde entonces la implementación de sistemas AMI por parte de las compañías eléctricas se ha
visto como una tendencia, a continuación serán mencionados algunos de los casos más relevantes:
Italia-Enel, La compañía eléctrica italiana ENEL, a través de un proyecto denominado AMM

(Automated Meter Management) instaló para fines del 2013 alrededor de 32 millones de
medidores inteligentes en Italia, cubriendo así el 90% de sus usuarios. El sistema AMI
instalado consta de: medidores inteligentes, concentradores, redes de comunicaciones (PLC y
5
celular) y un sistema central de gestión de medidores encargado de realizar la facturación y

monitoreo de la calidad de la red eléctrica. Los medidores se comunican con los
concentradores vía PLC. Los concentradores están comunicados por medió de redes GPRS
(celular) con las subestaciones eléctricas desde las cuales se realiza el monitoreo de
mediciones, alarmas, operaciones remotas, actualizaciones de firmware, etc. [7].
Suecia-Vattenfall, La compañía sueca de distribución Vattenfall a través del proyecto

"AMR/AMI and Advanced Meter Management System" entre el 2003 y el 2009 instaló cerca
de 860,000 medidores inteligentes en una primera etapa de un total de tres. La infraestructura
AMR/AMI consta de: medidores inteligentes, concentradores, sistemas de recolección, redes
de comunicaciones (PC, radio, celular y fibra óptica) y un sistema central de gestión de
medidores. Las redes de comunicaciones están implementadas en tres niveles. En el nivel 1
usa comunicaciones de radio de baja potencia (30%) o PLC (50%) para comunicar a los
medidores con los concentradores. En el nivel 2 se usa GPRS (15%) para comunicar a los
concentradores con el sistema de recolección AMR. En el nivel 3 entre el sistema de
recolección AMR y el sistema central de gestión de medidores se usan cuatro opciones: GPRS
(70%), red de telefonía pública (20%), radio de onda corta “SWR” (5%) y cableados privados
de fibra óptica o cobre (5%). También se puede ocupar comunicación directa entre algunos
medidores y el sistema central por medio de GPRS [7].
Canadá-Ontario, A través del proyecto "Ontario Smart Meter Deployment" del 2004 al 2012
instaló un total de 4.8 millones de medidores inteligentes para cubrir los 4,5 millones de
usuarios (entre residenciales y comerciales) de la ciudad de Ontario. Cada compañía de
distribución local fue responsable de su propia infraestructura y sistemas AMI, para integrarlos
finalmente a una central de gestión de datos y repositorio (meter data management repository
MDM/R) siendo este el sistema responsable de recolección de la información de cobro por
hora para enviarla más tarde a las compañías de distribución asociadas para la emisión y
entrega de facturación a todos los clientes finales [8].
Austria, A través del proyecto "Energy AG Smart Metering" se instalaron para finales del
2013 100,000 medidores inteligentes en el norte de Austria, pretendiendo alcanzar 600,000
medidores para el 2019. La infraestructura de este sistema AMI consta de medidores
inteligentes, concentradores, redes de comunicaciones (radio, fibra óptica y celular) y un
sistema central e gestión de medidores. La comunicación entre medidores inteligentes y
concentradores se realiza por medio de PLC, mientras que para comunica a los concentradores
con en el sistema central se utilizan: radio (63%), fibra óptica (33%) y GPRS (4%) [7].
Países Bajos, Por medio del proyecto "Smart Meter Deployment" entre 2012 y 2014 se
instalaron alrededor de 500,000 medidores digitales pretendiendo cubrir al menos el 80% de
los usuarios finales para antes del 2020 [7]. Para comunicar a medidores con concentradores
se utiliza PLC mientras que la comunicación entre concentradores y sistema central se realiza
6
por medio de PLC, adicionalmente se puede ocupar comunicación directa entre algunos
medidores y el sistema central por medio de GPRS [9].
USA-California, En Estados Unidos para el 2013 ya se habían instalado cerca de 37 millones

de medidores inteligentes en sistemas AMI y 45 millones en sistema AMR. Cerca de 10.5
millones de esos medidores AMI y 0.5 millones AMR estaban en el estado de California [7].
Cada uno de estos desarrollos incluye medidores inteligentes y las redes de comunicaciones
asociadas, lectura y control remoto, sistemas de gestión de datos, interacción con el cliente vía
portal web y esquemas de precios dinámicos. Las comunicaciones utilizadas han sido variadas
resaltando el uso de radios de corto alcance con tecnología malla y redes de fibra óptica, estas
últimas abarcando casi por completo los sistemas de distribución [10].
En Europa se presentan los casos más sobresalientes de implementación de sistemas AMI. A nivel
global la instalación de medidores inteligentes se cree que alcanzará casi los 800 millones para el
2020 siendo China quien tenga más de la mitad de estos, alrededor de 435 millones, seguido por
Estados Unidos con 132 millones, Japón con 58.7 millones, Reino Unido con 53 millones y Francia
con 35 millones [11]. Las tecnologías de comunicación más comunes son PLC, radio con
tecnología malla (Zigbee principalmente), GPRS, radios de largo alcance y fibra óptica.
En México la implementación de sistemas AMI hasta hace pocos años había sido moderada,
comenzando con sistemas pilotos en diversas regiones del país, algunos de los casos más
sobresalientes son enlistados a continuación:
Mexicali 2006, este proyecto entra en operación siendo el primer proyecto AMI en México
instalando alrededor de 10,000 medidores repartidos en tres zonas: Mexicali y Tijuana, Baja
California y posteriormente en La Paz, Baja California Sur. Los medidores son electrónicos y
utilizan comunicación inalámbrica tipo malla en la banda de los 900 MHz y también
comunicación vía celular (GPRS), para servicios residenciales, comerciales e industriales.
Como concentradores de datos utilizan algunos medidores especiales que además de medir el
consumo de algún usuario se encargan de recolectar los datos de los medidores vecinos y
enviarlos a un servidor directamente conectado a la CFE [12].
Polanco 2011, proyecto de implementación de una AMI en la zona residencial y comercial de

Polanco en la Ciudad de México. Este sistema inicialmente cambio los medidores individuales
de tipo analógicos por similares en forma e instalación pero del tipo digitales inteligentes,
posteriormente en los edificios y zonas comerciales se implementaron medidores de tipo socket
o gabinete, en este caso la comunicación a las pantallas de los usuarios se realiza vía PLC. Los
medidores utilizan redes “mesh” o maya bajo la tecnología Zigbee. Los datos son recibidos por
medidores especiales que se conectan directamente a servidores instalados en la CFE. Hasta el
2014 contaba con más de 29,660 servicios entre domésticos, comerciales de 2 y 3 fases, sistemas
de bombeo de agua potable, servicios a media tensión con tarifa ordinaria u horaria, e inclusive
7
medición directa en transformadores de distribución. A la fecha sigue en etapa de expansión

[13] [14].
Acapulco 2012, otro proyecto de implementación de AMI a gran escala en México, en este caso
se decidió por la ciudad de Acapulco, Guerrero debido a que era la que presentaba el mayor
índice de ilícitos relacionados al robo de energía de todo el país. El sistema implementado aquí
utiliza la tecnología TWACS, la cual es un tipo de PLC capaz de alcanzar largas distancias sin
necesidad de repetidores, capaz de cruzar los transformadores de distribución y viajar por las
redes de media tensión llegando así hasta las subestaciones. Los concentradores de datos se
encuentran directamente en las subestaciones de CFE. La principal desventaja de este sistema
es el costo tanto inicial como el de mantenimiento además de que implica un consumo de energía
mucho mayor al momento de transmitir datos y genera una gran distorsión armónica de las
ondas de corriente y voltaje. Adicionalmente las pantallas de usuario recibían datos desde los
concentradores vía PLC. Aun así el sistema ha dado buenos resultados a nivel comercial y por
ahora solo se ha ampliado hasta cubrir toda la ciudad de Acapulco Guerrero [15].
Cozumel 2012, se implementa en la ciudad de Cozumel, Quintana Roo un sistema AMR, con
la finalidad de monitorear los consumos de los usuarios finales de manera remota, el sistema
también cubre parte de la red de distribución [16].
Querétaro 2013, sistema instalado en la ciudad de Querétaro comenzando con 600 medidores
y alcanzando hoy los 120,000. También hace uso de tecnología “mesh” Zigbee como medio
entre medidores y concentradores pero su principal diferencia es que pretende implementar la
pantalla de usuario como otro dispositivo inteligente capaz de comunicarse con los
electrodomésticos de los hogares, es decir abarca la implementación de una HAN (ver sección
2.2.4.2). Es un sistema que ofrece más prestaciones del lado del usuario y ha sido diseñado y
respaldado por el Instituto de Investigaciones Eléctricas [17] [18].
Ciudad de México 2015, en Agosto del 2015 se hizo pública la noticia de que la CFE invertiría
alrededor de 6,500 millones de pesos en la actualización de los sistemas de medición eléctrica
en todo el país, comenzando como primeras etapas en la Ciudad de México y alrededores. Hasta
la fecha en diversas zonas de la Ciudad de México y el área metropolitana han sido remplazados
los medidores antiguos por los inteligentes, siendo varias compañías las encargadas de este
proceso. Muchas de estas han optado también por la tecnología “mesh” Zigbee pero ahora
también se han visto quienes se inclinaron hacia las redes “punto-a-punto” como la que utiliza
LoRa [19].
Otras ciudades, En diversos estados como lo son Querétaro, Guanajuato, Aguascalientes,

Tabasco, Chiapas, Zacatecas, Hidalgo, Coahuila, Chihuahua y Estado de México
principalmente, se ha comenzado a llevar a cabo la ejecución de la iniciativa de la CFE por el
cambio de sistemas de medición tradicional por sistemas tipo AMI, el propósito es que estén ya
8
operando para el 2017. Hasta ahora han sido responsabilidad de más de 22 empresas, utilizando
diversas tecnologías [20].
Para el desarrollo de este trabajo se tomaron como referencia algunas publicaciones internacionales
realizadas respecto a los sistemas AMI:
[21] Dicho artículo muestra los resultados de un sistema AMI implementado mediante una
tarjeta Raspberry Pi, la cual trata de emular a un conjunto de medidores generando datos ficticios
que serán subidos a una web en internet para su posterior análisis.
En [22] se muestra un sistema que simula a un medidor inteligente dentro de una AMI por medio
de una tarjeta Arduino y una Raspberry Pi, con la finalidad de evaluar el comportamiento de un
sistema AMI en un sistema de baja y media tensión.
En [23] se muestra el uso de una tarjeta Raspberry Pi como datalogger, almacenando las
mediciones de un medidor digital dentro de una base de datos en MySQL y subiéndolas a internet
por medio de un servidor web también programado en la Raspberry Pi. El objetivo final es
analizar la seguridad en los datos publicados.
Algunas normas y especificaciones que la CFE pone como referencia en nuestro país respecto a
los sistemas AMI son:
La norma [24] es una publicación internacional que a través de varias recomendaciones

generaliza los parámetros eléctricos que un medidor digital debe medir y la forma en que deberá
de entregar estos datos, así como las pruebas necesarias que debería de superar dicho medidor.
De manera similar está la [25] la cual ya es un estándar internacional enfocado en las

especificaciones que deben cumplir los medidores digitales.
La especificación [26] es un documento oficial publicado por la CFE con el fin de establecer las
bases generales y normas involucradas en sistemas de mediciones AMI en México a partir de
Abril del 2015, en este se detallan los puntos que debe cumplir el medidor digital como lo son
los parámetros eléctricos que deberá medir, los rangos máximos y mínimos de estos parámetros
a medir, alertas y eventos que deben detectarse y registrarse por parte del medidor, las
especificaciones y pruebas físicas que deben cumplir los medidores y en general toda la
información que debe ser transmitida por estos al resto de la AMI, sobre los concentradores de
datos y los sistemas de comunicaciones no pone restricciones por lo que da libertad a que los
interesados en desarrollar para la CFE realicen sus propias propuestas al respecto.
Adicionalmente también se tomaron referencias de tesis que involucran los conceptos de un sistema
AMI realizadas con anterioridad en la Sección de Estudios de Posgrado e Investigación de la
9
Escuela Superior de Ingeniería Mecánica y Eléctrica unidad Zacatenco, del Instituto Politécnico
Nacional.
En la tesis Diseño de Medidor Inteligente e Implementación de Sistema de Comunicación

Bidireccional [6] se realizó un prototipo de medidor digital que mediante análisis en el dominio
del tiempo y la frecuencia puede realizar las mediciones eléctricas de un sistema trifásico y
además es capaz de comunicarse mediante tecnología inalámbrica Zigbee a un concentrador de
datos el cual a su vez subía la información a una plataforma en línea.
De manera similar en la tesis Development of a Smart metering unit designed to identify energy
theft on distribution networks [27] se diseña un prototipo de medidor digital enfocado a detector
robos y alteraciones por parte del usuario, este prototipo es capaz de comunicarse con otros
dispositivos usando tecnología Zigbee para transmitir sus datos obtenidos y que estos puedan
visualizarse desde una plataforma web.
1.5 Alcances
Este trabajo de tesis presenta la investigación previa para poder realizar una propuesta de AMI.
Posteriormente se describe la metodología para su implementación práctica y pruebas realizadas,
todo con fines didácticos y de investigación.
Contempla el diseño en un sistema embebido de un Concentrador de Medidores Digitales capaz de

enviar y recibir datos a un gran número de dispositivos inteligentes (nodos y medidores), capaz de
enviar y recibir archivos a una o varias computadoras remotas dentro de una red TCP/IP y un
servidor FTP, además de ser controlado en tiempo real mediante una red VNC.
Cabe señalar que ningún componente propuesto, ni las pruebas realizadas o las metodologías
llevadas a cabo en este trabajo son estandarizadas, o se ejecutaron bajo normas en específico. Los
documentos que sean mencionados y comentados a lo largo de los capítulos solo sirvieron como
referencia con el único propósito de crear un sistema funcional.
10
1.6 Aportaciones
Una propuesta de un sistema AMI basado en un concentrador que puede ser implementado usando
una tarjeta de propósito general Raspberry Pi.
Este trabajo involucra todos los elementos de una AMI, la documentación del hardware y software
que se deja, puede ser usada en trabajos futuros, para implementar redes inteligentes.
Adicionalmente durante el desarrollo de este trabajo se publicó el artículo “Propuesta de AMI para
Smart Grid’s utilizando una red LoRaWAN” presentado en el XV Congreso Nacional de Ingeniería
Mecánica y de Sistemas organizado por la ESIME.
1.7 Estructura de la tesis
Capítulo 1: Se presenta una introducción sobre la temática de este trabajo de tesis, definiendo los
objetivos, justificación, el estado del arte, los alcances y la estructura de la tesis.
Capítulo 2: Se profundiza en la temática de las AMI las cuales forman la base de una Red Eléctrica
Inteligente, y se presentan los principales campos de investigación involucrados así como los
conceptos generales necesarios para la propuesta y el desarrollo de este trabajo. Al final de este
capítulo se hace la propuesta del Concentrador de Medidores Digitales así como del resto la AMI
necesaria para demostrar su funcionamiento.
Capítulo 3: Se presentan todos los componentes de hardware que dieron forma a los diferentes
dispositivos de la AMI propuesta, mostrando los detalles en diagramas de bloques de cada etapa,
así como también los diagramas esquemáticos y de conexiones necesarios.
Capítulo 4: Se presentan las funciones y los algoritmos programados implícitos en cada una de los
tres dispositivos de la AMI propuesta: MedidorE, NodoM y CMD.
Capítulo 5: Se muestran y explican detalladamente las pruebas realizadas a cada uno de los
componentes de la AMI propuesta, seguidas por los resultados obtenidos.
Capítulo 6: Se dan las conclusiones, aportaciones y recomendaciones para trabajos futuros

derivados al finalizar este trabajo de tesis.
Apéndice A: Se describen los sistemas de comunicaciones alámbricos e inalámbricos utilizados,

así como también los protocolos bajo los que estos operan.
11
Apéndice B: Se describen las especificaciones técnicas de cada componente de hardware que fue
utilizado para la implementación física de este trabajo de tesis.
Apéndice C: Se anexan las configuraciones necesarias para la FRDM-K64F utilizada así como el
código fuente en lenguaje C programado en el medidor emulado denominado MedidorE.
Apéndice D: Se anexan las configuraciones necesarias para la FRDM-K64F utilizada así como el
código fuente en lenguaje C programado en el dispositivo nodo denominado NodoM.
Apéndice E: Se anexan las configuraciones necesarias para la Raspberry Pi 2 utilizada así como
el código fuente en lenguaje Python 2.7 del programa datalogger.py el cual es ejecutado en el
concentrador de medidores digitales denominado CMD.
Apéndice F: Se anexan las configuraciones necesarias para crear la red LoRa utilizada para la
transmisión remota e inalámbrica de datos entre el CMD y el NodoM.
12
Capítulo 2: Marco teórico y

propuesta del prototipo de concentrador
A lo largo de este capítulo se pretende dar una breve explicación de los conceptos básicos
necesarios para el entendimiento del trabajo desarrollado en esta tesis, comenzando por los
conceptos de mediciones eléctricas, es decir de los parámetros de la energía eléctrica monitoreados
por un medidor inteligente, los conceptos de una Red Eléctrica Inteligente así como de una AMI y
las tecnologías informáticas o tecnologías de internet involucradas. Cabe mencionar que solo se
dan los conceptos bases implicados para este trabajo en específico ya que por cada tema o concepto
dado la definición y temas asociados son muchos mayores a los que se pueden abarcar en estas
pocas páginas.
2.1 Mediciones Eléctricas
Como su nombre lo dice la principal tarea de un medidor eléctrico será medir la energía eléctrica
recibida por un usuario final o consumidor, estás mediciones contemplan parámetros como el
voltaje y la corriente, la frecuencia, la potencia activa y reactiva, el factor de potencia y más
recientemente parámetros como la distorsión armónica total o THD por las siglas en inglés de Total
Harmonic Distortion. Mientras algunos de estos parámetros se miden directamente otros deben ser
medidos indirectamente, es decir deberán utilizar algoritmos especiales y basarse en datos
obtenidos o medidos previamente.
13
2.1.1 Conversión analógica a digital y muestreo de señales

Cuando se trata de un medidor digital los métodos para obtener las mediciones pueden ser variados,
dependiendo de la tecnología del dispositivo utilizado, del tipo y velocidad de procesamiento, de
los componentes utilizados como adecuadores de señales y la precisión que se requiera en la
medición de cada parámetro. Independientemente de lo anterior lo que siempre se cumple en un
medidor digital, por lo menos hasta ahora es la forma de tomar las mediciones.
El proceso de adquisición de datos parte de la conversión analógica a digital o ADC por sus siglas
en inglés, esto consiste en tomar una señal analógica y compararla con un valor de referencia fijo
y conocido, en base a esto se obtiene un valor numérico el cual podrá ser visto como un conjunto
de unos y ceros o mejor dicho un valor digital. Un medidor digital estará tomando muestras de una
señal durante intervalos constantes de tiempo (intervalo de muestreo) para hacer conversiones
analógicas a digitales de manera constante, esto es conocido como muestreo digital [28], entre
mayor sea el número de muestras mayor será la precisión de la medición pero también será mayor
el procesamiento de datos necesario. Mientras una señal eléctrica es variante en el tiempo, el cual
se considera constante, el muestreo digital se realiza durante intervalos por lo cual pasa a verse
como una señal discreta (ver figura 2.1),
Señal original en dominio

t
del tiempo
Señal muestreada a 2
n
KHz
Señal muestreada a 1
KHz n
Figura 2.1. Señal analógica convertida a digital con diferentes frecuencias de muestreo
Los procesadores y algoritmos de medición únicamente podrán trabajar con señales discretas, por
lo tanto es necesario adaptar todas las fórmulas de mediciones que estén en el dominio del tiempo
al dominio t de tiempo discreto n. Cabe destacar que una vez muestreada una señal podrá procesarse
para obtener su medición tanto en el dominio del tiempo como en el dominio de la frecuencia,
usándose esta última para aplicar procesamientos con auxilio de la Transformada Discreta de
Fourier [29] y la Transformada Rápida de Fourier [30]. La elección de estos métodos dependerá de
cada fabricante o diseñador, de cada tipo medidor y sus propósitos específicos.
Las dos señales básicas que un medidor digital monitorea de forma directa y permanente son el
voltaje y la corriente, ambos obtenidos mediante el muestreo de señales con ADC. Todos los demás
parámetros que obtiene un medidor digital son mediciones indirectas ya que estás serán obtenidas
o calculadas después de hacer el análisis del voltaje y la corriente.
14
2.1.2 Valor Eficaz o RMS

Cuando se mide una señal variante con el tiempo no se puede depender de solo una muestra ya que
la magnitud de la señal estará en constante cambio, se deben tomar una serie de muestras y a estas
se les sacará el promedio, este método denominado como obtención del valor medio solo
funcionara si la señal no es alterna, es decir que no cambia entre valores positivos y negativos
constantemente.
Si la señal es alterna entonces se deberán tomar una serie de muestras, elevarlas al cuadrado,
calcular su promedio y de este obtener su raíz cuadrada, la finalidad de elevar al cuadrado y después
obtener la raíz cuadrada es la de hacer que los valores negativos se conviertan en positivos y se
analicen con el restos de muestras. Este cálculo se conoce como el valor cuadrático medio o RMS
por las siglas en inglés de root mean square, también conocido como valor eficaz. Otra forma de
definir el valor eficaz o RMS es visualizarlo como el valor de una señal rigurosamente constante,
es decir que tendrá exactamente la misma energía que si se convirtiera en una señal continua. Si
fuese una señal de corriente alterna por ejemplo, la corriente eficaz es capaz de producir el mismo
trabajo que su valor en corriente directa o continua. El valor eficaz es independiente de la frecuencia
o periodo de la señal. Se puede definir como en la ecuación siguiente:
𝑇
1 (1.1)
𝑋(𝑡)𝑟𝑚𝑠 = √∫ [𝑥(𝑡)2 ]𝑑𝑡
0 𝑇
Donde Xrms es el valor eficaz de la señal, x(n) es la función discreta en el dominio de tiempo y T es
el tiempo que dura un ciclo. Para el caso de las señales eléctricas analizadas por los medidores
digitales, debido a que son senoidales alternas, la obtención y trabajo de valores RMS es
fundamental, y este será obtenido tanto en las señales de voltaje como en las de corriente, lo cual
implica que también se use para analizar las señales de potencia. Además como se trabajan con
señales muestreadas se deberá analizar de forma discreta, por lo tanto la ecuación (1.1) podrá verse
como:
𝑁−1
1 (1.2)
𝑋(𝑛)𝑟𝑚𝑠 = √ ∑ 𝑥(𝑛)2
𝑁
𝑛=0
Donde x(n) es la función periódica en el dominio de tiempo discreto y N es el número de muestras

de un ciclo.
2.1.3 Potencia Instantánea

La potencia en una señal eléctrica se define como el producto del voltaje v por la corriente i, esto
en cualquier instante del tiempo t, por lo cual también se denomina a esta p(t) como potencia
15
instantánea y será medida en watts [W], tal como expresa la ecuación (1.3) y (1.4) para potencia
instantánea discreta:
𝑝 = 𝑣(𝑡)𝑖(𝑡) (1.3) 𝑝 = 𝑣(𝑛)𝑖(𝑛) (1.4)
2.1.4 Potencia Activa

Debido a la naturaleza senoidal de la energía eléctrica, para medir la potencia no basta con la
potencia instante, será necesario más bien tomar una serie de muestras a lo largo de un periodo T,
así se obtendrá la potencia activa también denominada real o promedio y será medida también en
watts [W]; esto se expresa en la ecuación (1.5) y de forma discreta en la ecuación (1.6):
𝑁−1
1 𝑇 1
𝑃(𝑡) = ∫ 𝑝(𝑡)𝑑𝑡 𝑃(𝑛) = ∑ 𝑝(𝑛)
𝑇 0 (1.5) 𝑁 (1.6)
𝑛=0
2.1.5 Potencia Aparente

Si se vuelve a retomar la analogía de un circuito resistivo alimentado por una señal alterna con su
equivalente en corriente directa aparentemente el cálculo de potencia RMS debería dar el resultado
de potencia total consumida, esto solo se cumple cuando no existe ningún desfase entre corriente
y voltaje, es decir no hay cargas inductivas o capacitivas. Dicho lo anterior la forma de calcular la
potencia aparente es multiplicando el voltaje RMS por la corriente RMS, dicho resultado se medirá
en volt-amper [VA] y se expresa con la letra S como se ve en la ecuación (1.7), o en la (1.8) en su
forma discreta:
𝑆 = 𝑣𝑟𝑚𝑠 (𝑡)𝑖𝑟𝑚𝑠 (𝑡) (1.7) 𝑆 = 𝑣𝑟𝑚𝑠 (𝑛)𝑖𝑟𝑚𝑠 (𝑛) (1.8)
2.1.6 Potencia Reactiva

Un circuito eléctrico que presente cargas capacitivas o inductivas provocará un desfasamiento entre
la señal de voltaje y la señal de corriente. Los efectos de este desfasamiento se verán cuando se
presenta el instante justo en el que un valor de voltaje llega a su máximo, en ese momento la
corriente no podrá alcanzar también su máximo debido a su retraso y por lo tanto la carga del
circuito no podrá obtener en ese instante (y en ningún otro) la potencia máxima. Lo anterior se
puede ver como una pérdida de potencia que dependerá del valor de dicho desfase. Esta pérdida o
falta de capacidad para alcanzar la potencia máxima se le conoce como potencia reactiva la cual se
16
suele representar con la letra Q y en las mediciones eléctricas se puede expresar como volt-amper
reactivo [VAr]. Se representa normalmente con la siguiente ecuación:
𝑄 = √𝑆 2 − 𝑃 2 (1.9)
2.1.7 Tipos de cargas reactivas

Básicamente existirán dos tipos de cargas reactivas, las inductivas y las capacitivas. Pueden
considerarse como opuestas y generalmente son las cargas inductivas las que se encontraran de
forma natural debido a la presencia de motores y transformadores. Las cargas capacitivas se
colocarán de forma intencional generalmente con el propósito de compensar un exceso de las
inductivas.
Una carga inductiva al ser alimentado por energía alterna generará un campo magnético el cual
almacenará momentáneamente energía en forma de corriente que devolverá en cuanto el voltaje
comience a decrecer, este fenómeno producirá un desplazamiento o desfase negativo de la señal de
corriente con respecto a la señal de voltaje. Puede verse gráficamente en la figura 2.2 donde se
muestra también el triángulo de potencias correspondiente.
S
Q
Φ
P
Figura 2.2. Desfase negativo de la corriente y triangulo de potencias de la carga reactiva inductiva
Una carga capacitiva al ser alimentada por energía alterna generará un campo eléctrico en el cual
se almacenará momentáneamente energía en forma de voltaje que devolverá en cuanto la corriente
comience a decrecer, este fenómeno producirá un desplazamiento o desfase positivo de la señal de
corriente con respecto a la señal de voltaje. Puede verse gráficamente en la figura 2.3 donde se
muestra también el triángulo de potencias correspondiente.
Φ
Q
S
Figura 2.3. Desfase positivo de la corriente y triangulo de potencias de la carga reactiva capacitiva
17
2.1.8 Factor de Potencia

El desplazamiento entre voltaje y corriente mencionado anteriormente podrá ser medido por medio
de un ángulo el cual comúnmente es denominado como Φ = Φ𝑣 − Φ𝑖 , siendo Φ𝑣 el ángulo de la
señal de voltaje y Φ𝑖 el ángulo de la señal de corriente. Si se calcula el coseno de ese ángulo Φ se
obtendrá el factor de potencia, aunque también puede obtenerse al dividirse la potencia activa sobre
la potencia aparente tal como se muestra en la ecuación (1.10). Al tratarse de una relación entre
dos magnitudes el factor de potencia podrá expresarse con valores entre 0 y 1, aunque muy
comúnmente es expresado en porcentaje por lo que a la división anterior solo deberá multiplicarse
por 100, expresando así al factor de potencia con valores entre 0 y 100 %.
𝑆 (1.10)
𝑓𝑝 = cos Φ =
𝑃
En las figuras 2.2 y 2.3 se muestran los triángulos de potencias en los que pueden verse con más
detalle la relación del factor de potencia con las potencias activa, reactivan y aparente. Además con
estos triángulos puede obtenerse otra ecuación muy útil que relaciona directamente a la potencia
activa con la potencia reactiva y el ángulo de desfase, esta se expresa en la ecuación (1.11):
𝑄
tan Φ = ; 𝑄 = 𝑃 tan Φ (1.11)
𝑃
Con la ecuación (1.10) y (1.11) puede entonces obtenerse otra ecuación para relacionar a la
potencia reactiva con la potencia activa y el factor de potencia, se muestra en la ecuación (1.12):
Φ = cos−1 (𝑓𝑝) ; 𝑄 = 𝑃 tan(cos−1 (𝑓𝑝)) (1.12)
2.1.9 Energía activa y reactiva

Comprendidos los conceptos de potencia activa y reactiva se pueden entonces definir los de energía
activa y energía reactiva. La energía activa se obtendrá del producto de la potencia activa
consumida durante un periodo de tiempo, por estandarización la unidad de tiempo base es la hora,
mientras que la unidad de potencia activa será el kilo-watt es decir 1000 watts, resultando así que
la medición de energía activa sea medida en kilo-watt hora [kWh], en comparación con medidas
de potencia diferentes y con la medida del sistema internacional de energía, el Joule [J] se tienen
las siguientes equivalencias:
1000𝐽 (1.13)
1𝑘𝑊ℎ = 1000 𝑊ℎ = (3600 𝑠) = 3,600,000 𝐽
1𝑠
18
A diferentes valores de tiempo, por ejemplo th (tiempo en horas), tmin (tiempo en minutos) y ts
(tiempo en segundos), las equivalencias para obtener la energía en kilo-watts-hora se muestran en
estas otras ecuaciones:
𝑃 ∙ 𝑡ℎ 𝑃 ∙ 𝑡𝑚𝑖𝑛 𝑃 ∙ 𝑡𝑠
𝐸𝑃 = = = = [𝑘𝑊ℎ] (1.14)
1000 60 ∙ 1000 3,600 ∙ 1000
Para la energía reactiva la idea es la misma pero esta vez la que se multiplicara por una unidad de
tiempo es la potencia reactiva, quedando entonces como kilo-Volt-Amper-reactivo-hora [kVArh].
𝑄 ∙ 𝑡ℎ 𝑄 ∙ 𝑡𝑚𝑖𝑛 𝑄 ∙ 𝑡𝑠
𝐸𝑄 = = = = [𝑘𝑉𝐴𝑟ℎ] (1.15)
1000 60 ∙ 1000 3,600 ∙ 1000
Los algoritmos programados en los medidores digitales deberán monitorear ambas potencias
(activa y reactiva) para calcular los valores estimados cada segundo o incluso fracciones de tiempo
menores, después se deberán hacer los cálculos pertinentes para convertir la energía medida durante
esa fracción de tiempo en su equivalente en kWh o kVArh e ir sumando ese valor a la energía
obtenida y almacenada un momento anterior, proceso que será repetido permanentemente.
2.1.10 Frecuencia
Aunque este no es un parámetro indispensable a medir para la compañía eléctrica suele tomarse
como uno más de los valores instantáneos a medir por el medidor digital, normalmente se hace por
medio de la detección del cruce por cero entre un semiciclo positivo a negativo o al revés, una vez
que este cambio de signo en el semiciclo se detecta a partir de ese momento se comienzan a contar
el número de muestras hasta que un nuevo cambio de signo de la señal sea detectado. El número
de muestras contabilizado generalmente será un valor fraccionario por lo que se tienen que contar
las fracciones de muestras de un semiciclo anterior y del semiciclo posterior para después sumarlos
y obtener un valor mucho más cercano a un entero. Para este proceso se suele usar el método de
interpolación lineal. La unidad a mostrar por el medidor será en ciclos por segundo o Hertz [Hz].
2.1.11 Distorsión Armónica Total
Cada vez es más común que en la red eléctrica se conecten cargas no lineales, es decir todas
aquellas cargas que consumen voltaje y corriente en forma de pulsos, como es el caso de las fuentes
conmutadas presentes hoy en día en la mayoría de las fuentes de aparatos electrónicos modernos.
Estas cargas pulsantes cuando interactúan con la impedancia de la red eléctrica tienden a deformar
la forma de onda senoidal con la que se alimentan.
19
Teóricamente las señales eléctricas deberían tener una forma de onda senoidal pura, caso en el que
se dice que solo está presente la componente de frecuencia fundamental. Cuando existe
deformación en esta forma de onda se hablará entonces de la distorsión armónica. La distorsión
armónica es todo aquel ruido agregado a la señal de onda senoidal tanto de voltaje como de
corriente. Es decir serán todas las componentes de otras frecuencias múltiplos de la fundamental
que sumadas crean o se aproximan a la onda de corriente o voltaje deformada [31].
Algunos medidores son capaces de analizar y encontrar las frecuencias presentes en la forma de
onda analizada, esto requiere de un análisis más complejo mediante el uso de algoritmos como la
FFT y la DFT, así como otros métodos de procesamiento de señales. Un análisis más simple se
realiza mediante la comparación de los valores RMS de la señal eléctrica real y de la señal senoidal
pura, con estos se puede obtener un valor o índice para indicar el porcentaje de esta distorsión
presente en la señal analizada, este resultado es conocido como distorsión armónica total o THD
(siglas en inglés de Total Harmonic Distortion), la forma de obtener este THD en las señales
eléctricas senoidales se expresa en la ecuación (1.16):
√(𝑋𝑅𝑀𝑆 2 )2 + (𝑋𝑅𝑀𝑆 3 )2 + (𝑋𝑅𝑀𝑆 4 )2 +∙∙∙ +(𝑋𝑅𝑀𝑆 𝑛 )2

%𝑇𝐻𝐷 = × 100 (1.16)
𝑋𝑅𝑀𝑆 1
Debido a que normalmente solo se conocen los valores RMS de la señal analizada se pueden
comparar con el RMS de la fundamental, entonces la ecuación más fácil de utilizar es:
√(𝑋𝑅𝑀𝑆 )2 − (𝑋𝑅𝑀𝑆 1 )2 (1.17)

%𝑇𝐻𝐷 = × 100
𝑋𝑅𝑀𝑆 1
Donde XRMS es el valor RMS total de la señal analizada y XRMS 1 es el valor RMS de la señal senoidal
fundamental.
2.1.12 Valores para CFE
De acuerdo a la Especificación CFE G0100-05 [26] los medidores domésticos para baja tensión
deberán tener como datos accesibles para el administrador una serie de parámetros los cuales
pueden dividirse en valores instantáneos, valores a ser registrados y valores de eventos-alarmas.
Los valores listados a continuación son los principales datos que debe mostrar un medidor de CFE,
la lista es mucho mayor pero solo se verán modificaciones (por ejemplo en mediciones horarias,
mediciones por periodos, etc.) de los que a continuación se muestran.
Por el lado de los valores instantáneos se tienen a los siguientes:
20
 Potencia Activa [kW]

 Potencia Reactiva [kVAr]
 Potencia Aparente [kVA]
 Corriente [A]
 Voltaje [V]
 Factor de Potencia [F.P.]
 Frecuencia [Hz]
Los valores totales o acumulativos son respecto a los kWh o kVArh consumidos hasta el momento:
 Energía activa total [kWh]

 Energía reactiva total [kVArh]
Los eventos o alarmas son picos o sucesos detectados por el medidor durante un periodo de tiempo
establecido (puede ser cada 24 horas, cada 4 días, etc.), aunque en este punto también se consideran
cortocircuitos, desconexiones, programaciones, accesos, etc. solo se enlistas los que tienen que ver
con mediciones eléctricas:
 Demanda máxima de Potencia Activa [kW] [fecha] y [hora]

 Voltaje máximo detectado [V] [fecha] y [hora]
 Corriente máxima detectada [A] [fecha] y [hora]
 Factor de Potencia máximo detectado [F.P.] [fecha] y [hora]
Respecto al THD aunque aún no es requisito de la CFE aun, se ha considerado cada vez más debido
al creciente uso de cargas no lineales. Se cree que dentro de unos años las distorsiones armónicas
y problemas relacionados con armónicos serán objeto a monitorear continuamente y en cada
medidor con el fin de detectar a los usuarios que puedan poner en riesgo a la red, tal como sucede
hoy con las cargas reactivas.
2.2 Redes Eléctricas Inteligentes e Infraestructura de Mediciones

Avanzadas
Explicar que son las Redes Eléctricas Inteligentes o Smart Grids no puede hacerse de manera tan
sencilla, implica conocer los problemas que estas intentan resolver, las áreas que pretenden abarcar
y posteriormente la infraestructura que necesitan para poder lograrlo.
21
2.2.1 Definición de Red Eléctrica Inteligente

Smart Grid o Red Eléctrica Inteligente es un concepto surgido recientemente tras reunir diferentes
estrategias para vencer los retos actuales y futuros concernientes a las Redes Eléctricas. Smart Grid
es una manera genérica de referirse a la modernización de nuestras redes eléctricas actuales
implementando de manera masiva tecnologías de computo, infraestructura de comunicaciones,
redes, sensores, algoritmos de control, sistemas predictivos, inteligencia artificial nuevas
tecnologías de monitoreo, diagnóstico y gestión de datos, entre muchas otras [1].
2.2.2 Retos de una Red Eléctrica Inteligente

Para hacerse de una correcta definición será necesario explicar los principales objetivos que debe
cumplir una Red Eléctrica Inteligente [32]:
A. Integración con generación variable

El consumo de energía varía a cada momento por lo que los sistemas de generación convencionales
tratan de ser controlados en base a estas demandas de consumo ofreciendo aun así grandes picos
de sobre generación no aprovechables surgiendo de esto el objetivo más importante a cumplir por
una Red Eléctrica Inteligente: generar justo la energía que se consume. Por otra parte las fuentes
de generación renovable como la solar y la eólica no pueden controlarse creando así variabilidad
(picos y valles incontrolables de generación) e incertidumbre (debido a las condiciones climáticas
variables e impredecibles todo el tiempo), adicionalmente las variaciones en la frecuencia y niveles
de voltaje que presentan dificulta su integración con las redes eléctricas existentes, surgiendo así
un reto más para las Redes Eléctricas Inteligentes.
B. Transmisión automatizada
Evitar apagones de energía en grandes áreas. Con la interconexión de microrredes
gestionadas por Redes Eléctricas Inteligentes se podría no depender totalmente de los grandes
sistemas de generación, así en caso de algún problema con estos sistemas solo supondrían apagones
parciales en las grandes áreas alimentadas por los sistemas eléctricos de potencia actuales.
Protecciones tanto en zonas locales como en zonas amplias. Con la correcta implementación
de Redes Eléctricas Inteligentes la coordinación y modificación dinámica de relevadores digitales
así como las protecciones adaptables pueden ser llevadas a otro nivel gracias a la rapidez y
confiabilidad con la que los datos de consumo/generación por área son obtenidos.
Sistemas de Gestión de Energía y SCADA. En los grandes centros de control donde se toman
decisiones por zonas, se mantiene un constante monitoreo de valores como voltajes, corrientes y
frecuencias, si se complementan con los datos de las Redes Eléctricas Inteligentes se pueden
evaluar muchas otras magnitudes en tiempo real o casi real ampliando así las capacidades de toma
de decisiones y control en los actuales sistemas SCADA.
22
C. Distribución automatizada
Propiedad y uso de los datos entre clientes y proveedores de servicios. Para poder monitorear
en tiempo real el consumo o generación de cada cliente las Redes Eléctricas Inteligentes necesitan
de medidores inteligentes para recopilar la información necesaria de cada usuario enviándola a
concentradores y posteriormente a servidores informáticos. La seguridad de estos datos así como
un acceso remoto, transparente y en tiempo real tanto para usuarios como para los proveedores del
servicio eléctrico son cuestiones de seguridad indispensables.
Interfaz entre Activos de clientes, Recursos Distribuidos y Microrredes. Cuando un cliente
puede ser tanto consumidor como generador de energía la dirección de los flujos de potencia se
vuelve variante con el tiempo. Los medidores inteligentes son el principal recurso para monitorear
la dirección y los costos de estos flujos de potencia.
Mejora de la interacción entre la Distribución Automatizada y Sistemas de Transmisión
de Energía Masiva. Debido a la gran cantidad de microrredes surge la necesidad de implementar
herramientas digitales e informáticas para la adecuada sincronización de frecuencias, sistemas de
interconexión y protecciones con los sistemas eléctricos de potencia principales.
Calidad y confiabilidad de la red eléctrica. Las Redes Eléctricas Inteligentes también
pretenden mejorar los servicios de suministro eléctrico, garantizando la continuidad del servicio
mediante la anticipación a los altos picos de demanda y el monitoreo en tiempo real de valores de
consumo y generación, además de otras magnitudes como cargas reactivas y distorsión armónica
producida por zona o usuario; ofreciendo así un control continuo de la calidad de la energía.
D. Compromiso con el consumidor
Hogares, negocios e industrias inteligentes han sido la parte de las Redes Eléctricas Inteligentes
con mayor crecimiento y desarrollo actualmente. Debido a las recientes innovaciones tecnológicas
en cuanto a los sistemas de generación fotovoltaicos, de biomasa y de cogeneración principalmente
y de sistemas de almacenamiento como las baterías (considerando a las del inminente auto
eléctrico) surge el nuevo concepto de las “microrredes” donde ahora los consumidores también se
convierten en ciertos momentos en proveedores de energía eléctrica. Este surgimiento de
microrredes y sus respectivos retos de administración y aprovechamiento influirán ampliamente en
los precios de compra/venta de energía a cada momento por lo que las Redes Eléctricas Inteligentes
serán completamente indispensables.
E. Abierta a tecnologías emergentes

Estandarización e interoperabilidad. Con nuevos desarrollos tecnológicos surgiendo
alrededor del mundo a cada día la enorme oferta de soluciones posibles para una Redes Eléctricas
Inteligentes ha crecido de manera exponencial por lo que considerar estándares y normas es
esencial para que un sistema no sea dependiente de una sola tecnología ni mucho menos de un solo
fabricante, además de que debe garantizar la compatibilidad con nuevos sistemas y dispositivos
desarrollados así como los ya existentes asegurando su buen funcionamiento en conjunto.
23
Vehículos eléctricos. Se trata de una tecnología inminente cuya tendencia es sustituir a los
vehículos de gasolina por vehículos completamente eléctricos con baterías recargables como fuente
de alimentación principal. Estas baterías son de gran capacidad suponiendo una gran demanda de
energía para su recarga pero también pudiendo actuar como reservas de energía para la misma
Redes Eléctricas Inteligentes. Por lo anterior las Redes Eléctricas Inteligentes deben estar
preparadas para poder interactuar con estos vehículos los cuales deberán ser inteligentes para evitar
picos de saturación en la red durante su recarga y a su vez poder ofrecer de su energía de reserva
cuando se requiera.
Dispositivos inteligentes. Además de los automóviles hay una tendencia de casi cualquier
electrodoméstico y/o artículo eléctrico en hogares, comercios, oficinas e industrias por hacerse
inteligente, es decir que sea capaz de interactuar con la red para controlar las recargas de su batería,
sus horas de encendido y apagado así como reportar sus consumos.
Sistemas de almacenamiento de energía. Sistemas como las baterías de autos, baterías de
plomo-ácido en UPS, celdas de hidrógeno, súper capacitores, plantas de almacenamiento por
bombeo, sistemas flywheel, entre otras implementadas de forma masiva a las Redes Eléctricas
Inteligentes podrían permitir el mejor aprovechamiento de las fuentes renovables pero
intermitentes como el sol y el viento.
2.2.3 Conformación de una Red Eléctrica Inteligente

Teniendo claros los objetivos de una Red Eléctrica Inteligente se podrá hacer una división de esta
en cuatro subsistemas [2]:
AMI (Advanced Metering Infrastructure): o Infraestructura de Medición Avanzada es la

interfaz de comunicación entre el usuario (consumidor) y la red eléctrica, además de ser la parte
encargada de realizar la medición y el registro del consumo del usuario.
ADO (Advanced Distribution Operations): Operaciones de Distribución Avanzada, usará los

datos obtenidos por la AMI con el fin de poder mejorar las operaciones así como obtener datos de
la red eléctrica a nivel de distribución.
ATO (Advanced Transmission Operations): Operaciones de Transmisión Avanzada, usará los

datos de la ADO para mejorar el comportamiento y administración de la red eléctrica a nivel de
transmisión. Usará los datos de la AMI para que los usuarios tengan acceso al mercado.
AAM (Advanced Asset Management): usará la información de AMI, ADO y ATO así como los
datos medidos directamente de las centrales de generación para mejorar la eficiencia general de
toda la red eléctrica, y finalmente en este subsistema es donde se calculan los activos por cliente
respecto a su consumo energético.
24
TRANSMISIÓN
Figura 2.4. Estructura de una Smart Grid
En la figura 2.4 además de mostrar los subsistemas de una Red Eléctrica Inteligente también se
muestra la relación con los bloques de la red eléctrica a los que se atiende respectivamente.
Finalmente una Red Eléctrica Inteligente constituida además de mantener en óptimo
funcionamiento a la red eléctrica también establecerá una estrecha relación no solo con el usuario
final sino también con proveedores de servicios, diversos mercados y otros centros de operaciones.
25
2.2.4 Infraestructura de Mediciones Avanzadas (AMI)

Este subsistema, a través de medidores inteligentes se encargará de medir los datos de consumo de
energía eléctrica (y cada vez más comúnmente de generación) del cliente final, además de tomar
esas lecturas las almacena en un primer concentrador, el cual es básicamente una computadora que
se comunicará con una gran cantidad de medidores para tomar sus datos y almacenarlos. Este
concentrador es esencial ya que será el enlace con un limitado número de medidores generalmente
delimitados dentro de una zona geográfica. Este concentrador es el vínculo entre los medidores y
la red informática de la o las empresas que se encargarán de administrar la generación, transmisión
y distribución de la energía eléctrica. El concentrador también debe enviar información a los
medidores para hacer cortes o restablecimientos del servicio eléctrico, así como peticiones de
valores instantáneos o reconfiguraciones y actualizaciones. Adicionalmente este concentrador
también envía información al usuario mediante un dispositivo generalmente llamado IHD (In
Home Display) o pantalla en casa por sus siglas en inglés. Aquí se desplegará la lectura actual de
su medidor e incluso información como su nivel tarifario y el saldo actual por los KWh (Kilo Watt
hora) consumidos hasta el momento [33].
Puede verse con claridad que la base de una Red Eléctrica Inteligente es la AMI, ya que es ahí
donde todos los datos en cuanto a las necesidades y demanda de energía eléctrica son generados
además de que en la AMI se establece la relación directa entre la red eléctrica y el consumidor
quien como primer beneficiario tendrá un mayor nivel de satisfacción y por ende un mejor
comportamiento en cuanto a su consumo y pagos. Las AMI también pueden ser divididas en
subsistemas [34]:
2.2.4.1 Dispositivos Inteligentes
Son todos aquellos dispositivos físicos que conforman a una AMI. Aunque son muchas las
configuraciones posibles casi cualquier AMI involucra los siguientes 3 componentes:
Medidor Inteligente: es el corazón de las AMI, se trata de un dispositivo digital capaz de medir
potencia eléctrica RMS de forma bidireccional, es decir tanto consumo como generación, las
unidades básicas y acumulativas de medición de potencia eléctrica son el KWh (Kilo Watt hora)
para potencia activa y el KVARh (Kilo Volt Amper Reactivo hora) para potencia reactiva,
adicionalmente también proporcionará los valores instantáneos de otras magnitudes como lo son
Voltaje, Corriente, Frecuencia, Factor de Potencia y THD (Total Harmonic Distortion)
principalmente. El medidor inteligente también debe contar con otras características como lo son:
capacidad de corte y reconexión de servicio eléctrico de forma remota, transmisión de datos de
forma remota, capacidad de actualizar su configuración e incluso programación interna de manera
remota, memoria no volátil de datos acumulados. Manejar protocolos de comunicación
estandarizados para poder trabajar con múltiples dispositivos.
26
Concentrador de datos: subsecuente al medidor, el concentrador será una computadora capaz

de intercomunicarse con cientos o miles de medidores inteligentes. Será quien sincronice y lleve a
cabo la recopilación de mediciones y también quien transmitirá datos de configuración o
actualizaciones a los medidores inteligentes. También este concentrador enviará datos a otros
dispositivos inteligentes como lo son las pantallas dentro de los hogares de los usuarios. El
concentrador deberá tener una alta capacidad de procesamiento para poder transmitir, recibir,
procesar y almacenar una gran cantidad de datos por segundo. Deberá tener una gran capacidad de
memoria pues será la primera etapa de almacenamiento de datos recopilados de los medidores con
los que interconecta. Deberá soportar algún protocolo de comunicaciones estandarizado y
compatible con redes informáticas (TCP/IP) por lo que puede decirse que trabajará como servidor
web para así poder ser conectado por medio de red informática local, una intranet (por ejemplo la
de CFE) o incluso internet con el administrador final quien será el que ocupará los datos obtenidos
por la AMI. Al ser compatible con redes informáticas también deberá soportar sistemas de
seguridad informática. Por medio de esta comunicación informática el concentrador debe ser capaz
de transmitir y recibir datos continuamente, y también de recibir actualizaciones y cambios de
configuración de todos los medidores y otros dispositivos que gobierne.
En algunos casos dependiendo el tipo de AMI, se encontrarán además del concentrador principal
otros concentrados secundarios también llamados nodos, su propósito es concentrar una pequeña
cantidad de medidores cercanos con el fin de que compartan un mismo canal de comunicaciones
con el concentrador principal, estos son muy comunes en los medidores concentrados en gabinetes
por ejemplo.
Otros dispositivos: si hay otro dispositivo muy importante en las AMI es la IHD (In Home
Display) o pantalla en casa por sus siglas en inglés. Esta pantalla desplegará la información de la
potencia consumida por el usuario la cual previamente fue obtenida por el medidor inteligente. Esta
información a mostrar puede provenir directamente del medidor o del concentrador.
Adicionalmente la incorporación de otros dispositivos inteligentes del lado del hogar como
electrodomésticos, sistemas de calefacción y aire acondicionado, vehículos eléctricos y hasta los
sistemas de generación como paneles fotovoltaicos también formarán parte de la AMI.
2.2.4.2 Sistemas de Comunicaciones dentro de las AMI
Para que los dispositivos inteligentes de la AMI puedan intercambiar información entre ellos un
sistema de comunicaciones bidireccional será indispensable. Idealmente este debe permitir
comunicaciones remotas con distancias moderadas de alcance. En una AMI podremos encontrar
más de un sistema de comunicación por lo cual los sistemas de comunicación para intercomunicar
a los dispositivos inteligentes pueden clasificarse como alámbricos e inalámbricos:
Comunicaciones alámbricas: las comunicaciones alámbricas directas hacen uso de señales

eléctricas mediante comunicación serial, I2C, CAN, etc. y utilizan protocolos como MODBUS,
27
PROFIBUS, DNP3, etc. La principal desventaja de estos sistemas es que necesitan cableado
independiente. Hoy en día las comunicaciones PLC (Power Line Carrier) o portadora en línea
eléctrica por sus siglas en inglés se han posicionado como una buena opción para las AMI ya que
transmiten datos a gran velocidad por las mismas líneas de distribución de corriente alterna.
Adicionalmente hay que mencionar que las comunicaciones PLC tienen más de una variante,
algunas incluso patentadas como lo es el sistema TWACS el cual puede transmitir datos a baja
velocidad pero a grandes distancias a través de las líneas de media tensión.
Comunicaciones inalámbricas: generalmente trabajaran sobre bandas de radiofrecuencia

libres (como 433MHz/868MHz/915MHz). Hay varias topologías pero la más destacadas en las
AMI es la NAN (Neighbor Area Network) o red de área vecina por sus siglas en inglés, en esta un
nodo central se comunicara con los nodos próximos a él, a su vez estos nodos se conectarán con
otros nodos más lejanos a los cuales el nodo central ya no tiene alcance formando así una red del
tipo malla donde cada nodo además de ser un dispositivo final también actúa como retransmisor
de las señales del nodo principal; esta topología la podemos encontrar en radios ZIGBEE y
Bluetooth entre otros. Otra opción menos popular hasta el momento pero que debido a sus mejoras
de alcance promete ser una opción mejor son las redes de tipo (P2P) punto a punto donde toda la
información parte de un nodo central hacia muchos puntos o nodos, no hay comunicación directa
entre los nodos, cualquier dato debe pasar a través del nodo central. Algunos ejemplos típicos de
esta son: WiMax, GPRS, LoRa, MiFi, etc.
También se pueden clasificar los sistemas de comunicaciones de acuerdo a los dispositivos que
intercomunicaran quedando de la siguiente manera:
Comunicación Concentrador-Medidor: al requerir de una tasa de transferencia de datos muy

baja pueden usarse tanto los sistemas alámbricos como inalámbricos mencionados anteriormente,
esto será definido por cada fabricante, dependiendo mucho si se implementan medidores
individuales o concentrados en gabinetes.
Comunicación Concentrador-Desplegador: en la mayoría de los casos los medidores

inteligentes integran ya la pantalla donde el usuario final podrá ver sus consumos y datos
adicionales relacionados a su suministro eléctrico. En el caso de los medidores aislados en
gabinetes, se han dispuesto de pantallas para cada usuario, en estos casos la comunicación puede
realizarse directamente con el medidor, pero en otros se realiza directo con el concentrador
normalmente usando tecnología PLC.
Comunicación entre los dispositivos del usuario (HAN): un término mencionado

recientemente en las Red Eléctrica Inteligente es el de HAN (Home Area Network) o red de área
en el hogar, se trata básicamente de la última etapa de una AMI y es la que concierne
completamente al usuario ya que este será el que tendrá el control de la HAN la cual involucra a
todos los dispositivos inteligentes dentro de un hogar, comercio o industria como lo son sistemas
de calefacción, electrodomésticos, luminarias, contactos inteligentes, autos eléctricos, inversores
28
de sistemas solares, cogeneración, maquinaria industrial, etc. Esta HAN se puede llevar a cabo
mediante sistemas de comunicación alámbricos e inalámbricos (Wi-Fi, Zigbee, PLC) y en algunas
AMI la pantalla o desplegador será quien vincule a la HAN del usuario con el resto de la AMI
mientras que en otros casos se necesitan de alguna computadora u otro dispositivo adicional.
Comunicación entre Concentrador-Sistema Administrador de la AMI: en este caso el

sistema de comunicaciones deberá ser mucho más robusto en cuanto a su tasa de transferencia de
datos ya que por este medio se estarán transmitiendo simultáneamente todos los datos acumulados
en el concentrador y también se recibirá una gran cantidad de datos para actualizaciones o cambios
de configuración de los dispositivos inteligentes. Comunicaciones con soporte del protocolo
TCP/IP en diferentes medios (enlaces de fibra óptica o vía antenas terrestres de microondas por
ejemplo) son indispensables pues de esta manera se podrá garantizar la conexión a una red
informática (local, intranet o internet) que puede garantizar una transmisión de datos en tiempo
real.
2.2.4.3 Sistema Administrador de la AMI
Una vez obtenidos todos los datos de medición y ya disponibles en el concentrador, será el turno
del centro de control quien al estar enlazado directamente con los concentradores tomará todos los
datos a través de su red de comunicaciones. El centro de control es el encargado de procesar toda
la información, cargarla en sus diversas bases de datos y así proceder a su análisis para obtener
costos, consumos por hora, picos y valles en la demanda, identificar fallas o ilícitos, tomar
decisiones a nivel distribución, transmisión e incluso generación. Mediante los datos de medición
el centro de control además de poder establecer la generación de electricidad sobre demanda podrá
hacer uso de una gran cantidad de herramientas computacionales para realizar predicciones,
estimaciones, definir perfiles de consumo, aplicar sistemas de control inteligente entre muchas
cosas más que hasta el momento han sido solo teorizadas al no poder aplicarlas directamente en las
redes eléctricas por la falta de información en tiempo real.
29
Figura 2.5. Diagrama de una AMI implementada hoy en día
2.3 Tecnologías de Internet

Las Smart Grids o redes eléctricas inteligentes están basadas en el uso de diversas tecnologías de
la información con el fin interconectar a cada una de las etapas de la Red Eléctrica Inteligente entre
sí, prácticamente se pretende interconectar de forma directa o indirecta a todos y cada uno de los
componentes implícitos en la red eléctrica.
Como se detalló en la sección 2.2.4.2 los sistemas de comunicación entre los dispositivos
inteligentes podrán ser muchos, basados en diferentes medios, tecnologías y protocolos, de acuerdo
a sus necesidades y hasta el propio fabricante. Sin embargo para comunicar a las etapas principales
de la Red Eléctrica Inteligente (AMI, ADO, ATO y AAM) entre sí, se requerirá de una tecnología
estandarizada, de alta velocidad, que soporte largas distancias, flexible y que permita implementar
seguridad en los datos y en los accesos.
Aunque se generaliza el concepto como tecnologías de internet [35], no es aplicable únicamente a

internet, en realidad las siguientes definiciones pueden trabajar en redes informáticas de cualquier
30
tipo siempre y cuando soporten el protocolo TCP/IP (Transmission Control Protocol/Internet

Protocol) el cual se explica con detalle en el apéndice A.4.
2.3.1 Esquema cliente-servidor

Servidor, como la misma palabra indica, es un ordenador o máquina informática que está al
“servicio” de otras máquinas, ordenadores o personas llamadas clientes y que le suministran a estos
todo tipo de información. Por tanto un servidor en informática será un ordenador u otro tipo de
dispositivo que suministra la información requerida por los clientes (que pueden ser personas, o
también pueden ser otros dispositivos como ordenadores, móviles, impresoras, etc.) mediante la
aplicación de un programa servidor. De acuerdo al concepto anterior se crea entonces el
denominado esquema “cliente-servidor” que es uno de los más usados ya que en él se basa gran
parte de internet, pero también funciona para redes locales LAN, WAN e intranets.
Cliente: Es el ordenador que pide información a un servidor mediante la aplicación de un

programa llamado cliente. Este contacta con el servidor y da formato a la petición de la información
y a la respuesta.
Como muestra la figura 2.6, habrá una máquina servidor que se comunica con varios clientes, todos
demandando algún tipo de información. Esta información puede ser desde archivos de texto, video,
audio, imágenes, emails, aplicaciones, programas, consultas a base de datos, etc. El esquema cliente
servidor comúnmente trabaja bajo redes con el protocolo de red TCP/IP [Apéndice A.4].
Figura 2.6. Esquema cliente servidor
Adicionalmente se puede decir que el protocolo TCP/IP tiene múltiples subprotocolos de

aplicación para servidores como lo son el HTTP, el FTP, Telnet, POP, SMTP, P2P, entre muchos
otros. Solo se abordarán el HTTP y el FTP, ya que son los implicados en esta tesis.
31
2.3.2 Redes informáticas

En la figura 2.6 también se muestra que servidor y clientes deberán ser interconectados por un
medio físico, este será llamado red. En informática una red puede definirse como un conjunto de
equipos (computadoras, periféricos, etc.) que están interconectados y que comparten diversos
recursos. Este tipo de redes implica la interconexión de los equipos a través de ciertos dispositivos
que permiten el envío y la recepción de ondas, las cuales llevan los datos que se desea compartir.
En las redes informáticas, por lo tanto, hay emisores y receptores que intercambian mensajes [36].
El objetivo de una red informática es que los ordenadores puedan compartir sus recursos a
distancia. Otro de los fines de una red informática es la reducción de costes haciendo que solo una
computadora principal o servidor se encargue de tareas y/o procesos complejos mientras que
muchos usuarios en computadoras personales (más sencillas y económicas) accedan por medio de
la red a los resultados generados por el servidor, así la inversión principal estará en un único equipo.
De acuerdo al tipo de conexión, a la relación entre los elementos y al alcance, es posible clasificar
una red informática de las maneras siguientes:
Según el tamaño:
 LAN: red de área local se conectan varios equipos con un alcance limitado por los cables o
por la potencia de las antenas inalámbricas. Por ejemplo la red del instituto.
 MAN: red área metropolitana. Red formada por un conjunto de redes LAN en las que se
conectan equipos.
 WAN: red de área amplia interconectan equipos en un entorno muy amplio, como un país
usando la red telefónica.
Según el medio físico: Normalmente las redes suelen ser hibridas es decir redes LAN
alámbricas pero en las que alguno de sus nodos cuenta con un punto de acceso inalámbrico que
permite la conexión de otros dispositivos vía Wi-Fi.
 Redes alámbricas: utilizan cables coaxiales, pares trenzados, fibra óptica, etc. para
conectar a los equipos a un switch o router o para conectar ordenadores entre sí.
 Redes inalámbricas: La conexión inalámbrica se realiza mediante las ondas
electromagnéticas que se propagan entre una antena emisora y una receptora. El estándar
IEEE 802.11 popularmente conocido como Wi-Fi es el más común para estas redes.
Según la topología:
 Bus o lineal: tiene un cable central con derivaciones.
 Estrella: todos los ordenadores están conectados a un concentrador o Hub central y no
están conectados entre sí.
 Anillo: todos se conectan describiendo un anillo, la información llega a un ordenador si no
la necesita la pasa al siguiente.
 Malla: cada ordenador está conectado al resto de los equipos con más de un cable
32
Finalmente por medio de redes informáticas se crean las grandes redes, las cuales pueden dividirse
en tres dependiendo el nivel de accesibilidad que dan a los usuarios:
Internet: Comúnmente conocida como "La Red " o la "Red de Redes"; es un sistema de redes
informáticas por medio del cual una persona desde cualquier computadora puede acceder a
información de otra computadora e inclusive tener una comunicación directa con otros usuarios en
otras computadoras en otras partes del mundo. Todas estas computadoras se comunican usando el
protocolo de comunicación TCP/IP. Cualquier sistema conectado directamente a la red tiene un
nombre de dominio y un IP, este último es una dirección numérica.
Intranet: Es una red privada dentro de una organización que utiliza tecnología muy similar a la
de Internet la cual permite a sus usuarios buscar, utilizar y compartir documentos. Las empresas
utilizan el Intranet para comunicarse con sus empleados. En palabras técnicas, una Intranet, es una
red de Área Local o LAN la cual tiene la característica de ser de exclusivo uso, de la empresa u
organización que la ha instalado. Debido a ello, es que utiliza el protocolo TCP/IP. Adicionalmente
también suele interactuar con la Internet pero de forma controlada.
Extranet: también es una red privada corporativa destinada a compartir determinadas

operaciones e informaciones. Al igual que en la Intranet, emplea para su configuración y
funcionamiento los protocolos de la tecnología de Internet (IP), y se ubica privadamente en un
servidor al que tienen acceso únicamente las computadoras autorizadas. También puede utilizar el
sistema público de comunicaciones, es decir se puede accesar a esta por medio de Internet. La
Extranet es un anexo de la Intranet Corporativa, que partiendo de un diseño a medida de las
necesidades corporativas, habilita una parte de sus materiales para ser utilizada por personas ajenas
a la organización.
Tabla 2.1. Diferencias entre Internet, Intranet y Extranet
Internet Intranet Extranet
Acceso Público Privado Semi-público
Miembros de una Grupo de empresas estrechamente
Usuarios Cualquiera
compañía relacionadas
Compartida dentro de un círculo
Información Fragmentada Propietaria
de empresas
2.3.3 Servidores WEB o HTTP

Es el equipo o computadora que gestiona cualquier aplicación en el lado del servidor realizando
conexiones bidireccionales y/o unidireccionales y síncronas o asíncronas con los clientes. Debe
estar permanentemente conectado a la red (LAN, WAN, Intranet, Internet) ejecutando un programa
servidor web [37].
Programa servidor web: son los programas que se mantienen permanentemente a la espera de
peticiones hechas por clientes web. Los más populares son Apache, Microsoft IIS, Ngnix, Lighttp,
33
Sun Java System Web Server, etc. Una vez recibida una petición del cliente se encarga de procesar
los datos necesarios para entregar una respuesta en forma de página web o en cualquier lenguaje o
aplicación que pueda interpretar el cliente. El código enviado al cliente suele ser compilado y
ejecutado por un Navegador Web. Para la transmisión de todos estos datos se utiliza algún
protocolo como el HTTP (el más común) para estas comunicaciones, perteneciente a la capa de
aplicación del Modelo OSI e incluido en el protocolo TCP/IP.
Navegador Web: son aplicaciones que permiten ver en pantalla texto con formato (con palabras
en negrita, y con distintas fuentes tipográficas, tamaños y colores) y presentar imágenes en línea
además permiten visualizar secuencias de vídeo y escuchar ficheros de sonido. Para establecer
conexiones con los servidores Web, y obtener la información y los servicios que estos prestan, el
usuario necesita tener instalado en su equipo un programa cliente o navegador (Internet Explorer,
Google Chrome, Mozilla Firefox, Opera, etc.) capaz de comunicarse con ellos.
Página Web: Documento o fuente de información, generalmente en formato HTML y que

puede contener hiperenlaces a otras Páginas Web. Dicha página, podrá ser accesible desde un
dispositivo físico, una intranet, o Internet.
Protocolo HTTP: Una de sus características es que no es permanente, es decir, cada operación
HTTP implica una conexión con el servidor, que es liberada al término de la misma. Por ejemplo,
para un documento HTML con 10 imágenes son necesarias 11 conexiones distintas (10 imágenes
más la página HTML en sí).
Aplicaciones del lado del servidor: Es cualquier programa o conjunto de instrucciones

diseñadas con la finalidad de que un servidor Web las procese para realizar alguna acción. Las
aplicaciones del lado del servidor están escritas mediante un lenguaje de programación, entre los
que más se utilizan están: PHP, ASP, Perl, Python, Ruby, etc.
Aplicaciones en el lado del cliente: el cliente Web es el encargado de ejecutarlas en la máquina

del usuario. Son las aplicaciones tipo Java "applets" o Javascript. El servidor proporciona el código
de las aplicaciones al cliente y éste las ejecuta mediante el navegador Web. Por tanto, es necesario
que el cliente disponga de un navegador con capacidad para ejecutar aplicaciones (también
llamadas Scripts). Generalmente, los navegadores permiten ejecutar aplicaciones escritas en
lenguaje Javascript y Java, aunque pueden añadirse más lenguajes mediante el uso de plugins.
Socket: No son más que puntos o medios de comunicación entre dos aplicaciones que permiten
que un proceso hable (emita o reciba información) con otro proceso estando los dos en distintas
máquinas. Si extrapolamos el concepto a la comunicación entre personas, un socket es al sistema
de comunicación entre ordenadores lo que un teléfono es al sistema de comunicación entre
personas: un punto de comunicación entre dos agentes (procesos o personas respectivamente) por
el cual se puede emitir o recibir información.
34
2.3.4 Servidores FTP
Equipo o computadora que estará ejecutando un programa bajo el protocolo FTP o File Transfer
Protocol por sus siglas en inglés. Este es un protocolo de transferencia de archivos perteneciente a
la familia TCP/IP. Es utilizado para tener acceso a un anfitrión (host) y posteriormente para
transferir archivos entre ese anfitrión y la computadora que hace la conexión (usuario). Puede estar
conectado tanto a Internet como a otros tipos de redes privadas [38].
Programa FTP: Su función es permitir el intercambio de datos entre diferentes

servidores/ordenadores. Por lo general, los programas servidores FTP no suelen encontrarse en los
ordenadores personales, por lo que un usuario normalmente utilizará el FTP para conectarse
remotamente a uno y así intercambiar información con él. Las aplicaciones más comunes de los
servidores FTP suelen ser el alojamiento web, en el que sus clientes utilizan el servicio para subir
sus páginas web y sus archivos correspondientes; o como servidor de backup (copia de seguridad)
de los archivos importantes que pueda tener una empresa. Para ello, existen protocolos de
comunicación FTP para que los datos se transmitan cifrados, como el SFTP (Protocolo de
Transferencia de Archivos Seguro).
Cliente FTP: Cuando un navegador no está equipado con la función FTP, o si se quiere cargar
archivos en un ordenador remoto, se necesitará utilizar un programa cliente FTP. Un cliente FTP
es un programa que se instala en el ordenador del usuario, y que emplea el protocolo FTP para
conectarse a un servidor FTP y transferir archivos, ya sea para descargarlos o para subirlos.
Algunos clientes de FTP básicos en modo consola vienen integrados en los sistemas operativos,
incluyendo Microsoft Windows, DOS, GNU/Linux y Unix. Sin embargo, hay disponibles clientes
con opciones añadidas e interfaz gráfica. Aunque muchos navegadores tienen ya integrado FTP, es
más confiable a la hora de conectarse con servidores FTP no anónimos utilizar un programa cliente.
Acceso anónimo: Los servidores FTP anónimos ofrecen sus servicios libremente a todos los
usuarios, permiten acceder a sus archivos sin necesidad de tener un 'Usuario Registrado' o una
cuenta de usuario. Es la manera más cómoda fuera del servicio web de permitir que todo el mundo
tenga acceso a cierta información sin que para ello el administrador de un sistema tenga que crear
una cuenta para cada usuario.
Cliente FTP basado en Web: no es más que un Cliente FTP al cual podemos acceder a través
de un Navegador Web sin necesidad de tener otra aplicación para ello. El usuario accede a un
servidor web (http) que lista los contenidos de un servidor ftp. El usuario se conecta mediante http
a un servidor web, y el servidor web se conecta mediante ftp al servidor ftp. El servidor web actúa
de intermediario haciendo pasar la información desde el servidor ftp en los puertos 20 y 21 hacia
el puerto 80 http que ve el usuario.
Tipos de transferencia de archivos en FTP: Es importante conocer cómo se transporta un

archivo a lo largo de la red. Si no se utilizan las opciones adecuadas se puede destruir la información
35
del archivo. Por eso, al ejecutar la aplicación FTP, se debe de utilizar uno de estos comandos (o
poner la correspondiente opción en un programa con interfaz gráfica):
 Tipo ASCII: Adecuado para transferir archivos que sólo contengan caracteres imprimibles
(archivos ASCII, no archivos resultantes de un procesador de texto), por ejemplo páginas
HTML, pero no las imágenes que puedan contener.
 Tipo binario: Este tipo es usado cuando se trata de archivos comprimidos, ejecutables para
PC, imágenes, archivos de audio.
2.3.5 Bases de datos y Big Data

Una base de datos es el conjunto de datos informativos organizados en un mismo contexto para su
uso y vinculación. Se le llama base de datos a los bancos de información que contienen datos
relativos a diversas temáticas y categorizados de distinta manera, pero que comparten entre sí algún
tipo de vínculo o relación que busca ordenarlos y clasificarlos en conjunto.
Una base de datos puede ser de diversos tipo, desde un pequeño fichero casero para ordenar libros
y revistas por clasificación alfabética hasta una compleja base que contenga datos de índole
gubernamental en un Estado u organismo internacional. Recientemente, el término base de datos
comenzó a utilizarse casi exclusivamente en referencia a bases construidas a partir de software
informático, que permiten una más fácil y rápida organización de los datos. Las bases de datos
informáticas pueden crearse a partir de software o incluso de forma online usando Internet. En
cualquier caso, las funcionalidades disponibles son prácticamente ilimitadas.
Las bases de datos se clasifican como estáticas cuando sólo sirven para su lectura y
almacenamiento; o dinámicas cuando el tipo de información puede ser modificada y actualizada.
También, según su contenido pueden ser bibliográficas, de texto completo, directorios, o de tipo
biblioteca [39].
En el caso de las Redes Eléctricas Inteligentes las bases de datos son el destino final de todos los
datos recopilados por la AMI, desde mediciones, alarmas, eventos, modificaciones, accesos por
parte de los administradores y prácticamente cualquier suceso registrado. Estas bases de datos son
gestionadas por el administrador final en este caso la CFE.
Big Data: se denomina así a la gestión y análisis de enormes volúmenes de datos que no pueden
ser tratados de manera convencional, ya que superan los límites y capacidades de las herramientas
de software habitualmente utilizadas para la captura, gestión y procesamiento de datos. Dicho
concepto engloba infraestructuras, tecnologías y servicios que han sido creados para dar solución
al procesamiento de enormes conjuntos de datos estructurados, no estructurados o semi-
36
estructurados que pueden provenir de sensores, micrófonos, cámaras, escáneres médicos,

imágenes.
El objetivo de Big Data, al igual que los sistemas analíticos convencionales, es convertir el Dato
en información que facilita la toma de decisiones, incluso en tiempo real. Sin embargo, más que
una cuestión de tamaño, es una oportunidad de negocio. Las empresas ya están utilizando Big Data
para entender el perfil, las necesidades y el sentir de sus clientes respecto a los productos y/o
servicios vendidos. Esto adquiere especial relevancia ya que permite adecuar la forma en la que
interactúa la empresa con sus clientes y en cómo les prestan servicio.
No obstante, el asociar el concepto Big Data a grandes volúmenes de datos no es nuevo. La gran
mayoría de las empresas ya llevan mucho tiempo manejando grandes volúmenes de datos y han
desarrollado DataWarehouses y potentes herramientas analíticas que les permiten tratar de forma
adecuada esos grandes volúmenes. La evolución de la tecnología y los menores costes del
almacenamiento han hecho que los volúmenes manejados por estas aplicaciones hayan aumentado
de manera muy importante.
Big Data es uno de los temas centrales en las Redes Eléctricas Inteligentes ya que toda esa
información obtenida no solo será utilizada para facturar la venta de energía, sino también será
utilizada con el fin de mejorar el servicio ya que se podrá registrar el comportamiento de la red
eléctrica y de los usuarios ante circunstancias muy variadas anticipándose así a fallas y mejoras en
la eficiencia y generación, así como una mejor integración de las microredes y energías renovables
[40].
2.4 Propuesta de AMI

En la introducción de esta tesis (sección 1.1), se dio a conocer el tipo de AMI que se pretende
implementar con la finalidad de probar la funcionalidad del Concentrador principal propuesto.
Omitiendo a las interfaces de usuario o pantallas se hacen entonces la propuesta que será
desarrollada a lo largo de los próximos capítulos. Se muestra a continuación el diagrama final de
la AMI que será desarrollada e implementada (figura 2.7), se puede observar que se partió del
diagrama mostrado en la figura 1.1.
37
Administrador
Figura 2.7. Diagrama de la AMI propuesta para este trabajo de tesis
2.4.1 MedidorE
El Medidor Inteligente se considera la base de la AMI así como la AMI se considera el primer
eslabón en la Red Eléctrica Inteligente, por lo que se hace completamente necesario un prototipo
de medidor inteligente con el cual realizar las pruebas e implementación en la propuesta de este
trabajo. Debido a que el medidor inteligente no es el objetivo final en esta tesis, se optó por
desarrollar un emulador con el cual se estarán obteniendo mediciones ficticias pero cumpliendo
con los estándares de comunicaciones necesarios para poderlo implementar con los demás
componentes de este trabajo. El prototipo desarrollado en esta tesis se llama MedidorE, siendo la
letra E por ser emulado. Se propone para esta AMI el concepto de medidores de tipo gabinete
38
aislados del usuario. Estos medidores se concentran en grupos, repartidos en gabinetes, estos
gabinetes a la vez estarán aislados del usuario, para que el usuario no tenga acceso a ellos,
generalmente puestos sobre los postes de la CFE o en áreas especiales de edificios y comercios
(ver figura 2.8).
Gabinete varios medidores
aislados
Figura 2.8. Sistema de medidores en gabinetes aislados
Los medidores conceptuales de esta AMI son del tipo monofásico a dos hilos, basados en la
conexión eléctrica del [26] los cuales cuentan solo con 4 terminales, dos para medir voltaje y dos
para corriente que a su vez se conectarán en serie con el cable de línea viva para controlar la
conexión o desconexión del usuario (ver figura 2.9).
N
Carga
L
A
Figura 2.9. Diagrama esquemático de medidor tipo 1S monofásico a dos hilos sugerido
La razón de usar solo medidores monofásicos es porque con ellos se pueden armar las
configuraciones más comunes para usuarios de baja tensión (ver figura 2.10):
a) monofásico a tres hilos, dos elementos,

b) trifásico a tres o 4 hilos 3 elementos
c) trifásico tres hilos dos elementos.
39
a b L1
A
V
c
L1
L1
A A
V A
V
N
L3
V
L2
N
L2
V A
V
A V
L2 A
L3
Figura 2.10. Configuraciones más comunes con medidores tipo 1S para usuarios a baja tensión
Las tareas a cumplir para este MedidorE son:
1. Se pretende que este sea un medidor aislado del usuario (en lugar de ir junto a la casa o
inmueble del usuario irá en un gabinete con más medidores, más cercano de las
instalaciones de la compañía proveedora de energía) cuya tarea principal es medir
parámetros eléctricos consumidos por el usuario y trasmitirlos en forma de datos al
dispositivo que lo administre. No interactuará ni transmitirá información de forma directa
con el usuario.
2. El medidor (en esta tesis) estará emulando a un medidor real, generando valores aleatorios
para simular mediciones ficticias de los principales parámetros eléctricos que son medidos
por un medidor real.
3. Hará el respaldo de las mediciones acumulativas como KWh y KVArh, así como otros
parámetros importantes en una memoria no volátil.
4. El medidor debe funcionar en una red conectado a muchos otros medidores y también al
nodo, por lo que una red multidispositivos maestro-esclavos sería ideal.
5. Los datos obtenidos (o generados) por el medidor deben ser fácilmente accesibles por la
red AMI, es decir serán obtenidos por el nodo, concentrador y/o directamente por el sistema
administrador.
6. El medidor estará continuamente esperando un mensaje de verificación por parte del nodo,
si no recibe dicho mensaje se desactivará (desconectando al usuario de la red eléctrica).
7. El medidor simulará la conexión o desconexión del usuario a la red eléctrica por medio de
algún LED u otro dispositivo visual.
40
2.4.2 NodoM
Para esta propuesta de AMI el Medidor Inteligente será administrado por un componente que se
ha llamado NodoM, Nodo por ser un punto intermedio y M referente a medidores. Su propósito
general es administrar e intercomunicar desde uno hasta 254 medidores con el concentrador. El
NodoM se tiene visualizado como un componente físico más que irá en el interior de cada gabinete
junto con los medidores que estará administrando (ver figura 2.6). Debido a que los medidores
propuestos trabajarán en una red maestro-esclavos se requiere de un dispositivo que actué como
maestro el cual será el encargado de gestionar a todos los esclavos (medidores) conectados a él,
los esclavos nunca actuarán sin antes recibir una orden o mejor dicho petición del maestro. El
NodoM a veces actuará como maestro, en otras como esclavo y en otras como intermediario entre
maestro y esclavos. Las tareas que realizará este NodoM pueden enlistarse de la siguiente manera:
1. Con el fin de concentrar y administrar a más de un medidor en un solo punto (muy útil por
en edificios con departamentos o tiendas y centros comerciales con múltiples usuarios
concentrados en una zona relativamente pequeña) se plantea este NodoM como dispositivo
que pueda interconectar a múltiples medidores en una misma red.
2. Este dispositivo también se comportará como un primer Gateway ya que será un punto de
unión entre la red alámbrica de medidores y la red inalámbrica que comunica con el
concentrador.
3. Para la lectura de mediciones remotas así como para la escritura de ciertos parámetros el
concentrador será el maestro quien da las órdenes a los esclavos (medidores) decidiendo
que esclavo recibe o trasmitirá datos. En este caso el NodoM es un intermediario pasando
los mensajes entre el maestro y los esclavos.
4. El NodoM tendrá una lista con los números de serie de cada medidor que administra, solo
los medidores correctamente agregados en esta lista podrán estar activos (conectando al
usuario a la red) y ser intercomunicados con el concentrador.
5. El NodoM estará continuamente enviando un mensaje de verificación para mantener
funcionando a cada medidor que tiene en su lista, de esta manera se restringe a que los
medidores solo pueden funcionar en el NodoM en el que hayan sido agregados y de no ser
así se apagarán (desconectando al usuario) ya que no recibirán el mensaje de verificación.
En este caso el NodoM será quien controla a los medidores esclavos.
6. El NodoM será también administrado y modificado cuando sea necesario por el
concentrador, por lo que para este caso se comportará como un esclavo recibiendo órdenes
del concentrador.
41
2.4.3 CMD
Además de ser el objetivo principal de esta tesis, el CMD aquí propuesto es el equivalente al
concentrador para algunos casos o al “Gateway” en otros, en cada AMI, estos dispositivos son
nombrados de muchas maneras, a veces con funciones muy similares pero en otras muy diferentes,
dependiendo básicamente de las tecnologías que se usen, de las tareas que realicen y de la
arquitectura de diseño.
Mientras que con un NodoM se pretende concentrar en un solo punto a múltiples MedidorEs, con
un CMD se pretende concentrar a muchos NodoM pero en un área geográfica que cubre un radio
de cientos de metros e incluso kilómetros, por lo tanto podría describirse como un Concentrador
de Medidores Digitales a gran escala, de ahí su nombre abreviado de CMD. Con el sistema
implementado en esta tesis solo podrán monitorearse 100 MedidorEs como máximo cada 10
minutos aunque los cálculos estimados (ver sección 6.3) hablan de muchos más.
Como definición del CMD se puede decir que es la etapa que controla a la AMI y la conecta con
la red de la compañía encargada de tomar las mediciones como por ejemplo CFE en México
(Sistema Administrador). Las tareas del CMD se enlistan a continuación:
1. Se comportará como un concentrador ya que controla y monitorea a una gran cantidad de
medidores.
2. Funcionará como un “datalogger” (dispositivo registrador de datos) ya que en su memoria
interna guardará en archivos las mediciones eléctricas obtenidas por cada MedidorE.
3. Funcionará como un “Gateway” es decir como puente entre dos redes diferentes,
inalámbrica punto a punto por el lado de la infraestructura AMI y TCP/IP por el lado del
Sistema Administrador.
4. Funcionará también como un servidor FTP, trabajando bajo el protocolo FTP con el cual
podrá accederse mediante una red informática, esto permitirá el acceso remoto a los
archivos de mediciones y a los archivos de configuración.
5. Debe administrar los archivos para configurar a los NodoM, a los MedidorE agregados a
cada NodoM, a los radios de la red inalámbrica y a la AMI en general.
6. Es una computadora con acceso remoto que permitirá monitorear a la AMI en tiempo real.
2.4.4 Sistema Administrador

El sistema administrador puede resumirse como la institución, empresa, lugar o equipo que recibe
toda la información de la AMI, al tratarse de una red informática se tratará de una red privada o
mejor dicho una intranet, donde se recibe la información de los parámetros eléctricos medidos en
toda una zona, ciudad o región, de muchas redes AMI a la vez, en nuestro país esta empresa es la
42
Comisión Federal de Electricidad. Para este proyecto en específico el sistema administrador será
el punto final de la AMI al cual un usuario o mejor dicho administrador podrá accesar a través de
una computadora desde la cual podrá tanto visualizar el estado de la AMI, visualizar los datos de
medición obtenidos y poder reconfigurar o modificarla por completo de forma remota.
Las tareas asignadas a esta última parte llamada Sistema Administrador de la AMI propuesta son
las siguientes:
1. Es la interfaz final a la que tendrá acceso el usuario administrador de la AMI, mediante la

cual se podrán interactuar, monitorear y dar de alta y/o baja nuevos CMD, NodoM y
MedidorE´s, se podrán tener acceso a todas las mediciones registradas y se podrá modificar
la red inalámbrica LoRa así como el comportamiento y la estructura general de la AMI.
2. Acceder a la AMI indirectamente por medio del acceso al servidor FTP del CMD.
3. Acceder a la AMI indirectamente viendo los archivos de mediciones y modificando los
archivos de configuración a través de teléfonos móviles, tabletas y muchos otros
dispositivos inteligentes con acceso a la web.
4. Acceder a la AMI directamente a través del control total del CMD por medio de una
conexión remota.
5. Modificar, detener o reiniciar las tareas programadas de la AMI, así como crear y ejecutar
nuevos programas.
6. Monitorear y modificar la red informática, tarea generalmente realizada con exploradores
de internet.
2.4.5 Sistemas de comunicación en la AMI propuesta

Para definir el sistema de comunicaciones entre unos dispositivos con otros dentro de la AMI que
se propone en este trabajo es necesario visualizar las necesidades que presenta cada etapa, por lo
que los sistemas de comunicación se han dividido de la siguiente manera:
2.4.5.1 Comunicación Medidor - NodoM

Se decidió utilizar como medio físico una red RS485 ya que cumple con los siguientes objetivos:
1. Ser alámbrica.
2. Utilizar el menor número de hilos posibles.
3. Ser confiable ante interferencias y ruido.
4. Permitir la interconexión de múltiples dispositivos.
5. Ser del tipo maestro-esclavos.
6. Soportar un protocolo de comunicaciones estándar que permita detección de errores.
.
43
2.4.5.2 Comunicación NodoM - CMD

En este caso la red elegida ha sido una red LoRa ya que cumple con los siguientes puntos:
1. Ser inalámbrica punto a punto.
2. Permitir trabajar con múltiples dispositivos.
3. Tener un largo alcance.
4. Ser confiable ante interferencias y ruido.
5. Ser segura ante intervenciones de terceros (presentar algún tipo de cifrado o encriptación).
6. Ser de fácil interacción con los dispositivos a los que conectará.
7. Ser configurable mediante alguna herramienta amigable.
8. Deseable que sea configurable mediante comandos (para permitir configuración remota).
2.4.5.3 Comunicación CMD – Sistema Administrador

Finalmente para este enlace se optó por utilizar una red informática de área local del tipo LAN
(local área network por sus siglas en ingles) que soporte el protocolo cliente servidor TCP/IP. Esta
fue óptima ya que cumple con los siguientes requisitos:
1. Poder comunicar a un administrador con múltiples CMD.

2. Tener un ancho de banda suficientemente grande como para poder monitorear a la AMI en
tiempo real.
3. Ser robusta ante interferencias y ruido.
4. Ser segura ante intervenciones de terceros (presentar algún tipo de cifrado o encriptación).
5. Trabajar bajo un protocolo estándar para asegurar compatibilidad con múltiples equipos y
programas, así como la detección de errores.
6. Ser configurable.
44
Capítulo 3: Integración de
Hardware y de los Sistemas de
Comunicaciones
En el capítulo anterior (sección 2.5) se describió la propuesta de AMI a implementar en este trabajo
de tesis, se describieron los componentes principales y para cada uno se elaboró una lista con las
tareas más importantes que ha de realizar o cumplir. En este capítulo se retoman esas listas y se
relacionan con los componentes de hardware necesarios para cumplir cada punto y así poderlos
implementar de forma física y funcional dentro de la AMI propuesta. Se describen además los
buses y puertos de comunicación necesarios para interactuar unos con otros mostrando su
relaciones y conexiones mediante diagramas.
En este mismo capítulo se hablará de los sistemas de comunicaciones que se implementaron para
intercomunicar a todos los componentes de la AMI que se propuso y se dará introducción a los
protocolos de comunicaciones que utilizan, estos protocolos serán implementados posteriormente
en la programación mostrada en el capítulo siguiente.
Finalmente se muestran los diagramas de conexiones físicas del hardware de cada componente.
45
3.1 Hardware de los Dispositivos de la AMI
3.1.1 MedidorE
A continuación se mostrarán los componentes de hardware utilizados para crear el emulador de
medidor inteligente MedidorE mencionado en la sección 2.5.1. Se ponen primero los puntos a
cumplir para el hardware y después se menciona al componente que se eligió. Comenzando con el
dispositivo programable:
 Se requiere un microcontrolador con una velocidad de procesamiento preferentemente
mayor a los 20 MHz para generar los valores de medición ficticios, correr todas la funciones
necesarias y comportarse como esclavo bajo el protocolo MODBUS, además de contar con
una memoria tipo FLASH (usada como registro no volátil para las variables KWh y
KVArh).
 Es necesario que el microcontrolador cuente con una herramienta de programación rápida
y fácil de ejecutar así como una herramienta de depuración que permita monitorear todos
sus registros y variables y poder correr cada línea de código programada para encontrar los
posibles errores y/o mejorar el programa.
 Más que un microcontrolador se requiere de una tarjeta de desarrollo en la que el
microcontrolador esté montado, además dicha tarjeta debe estar equipada con todos lo
necesario como fuentes, terminales de entradas y salidas, sensores, acceso directo a los
puertos de comunicación y demás periféricos como resistores, capacitores, relojes y otros
circuitos integrados necesarios para su óptimo funcionamiento, además de uno o más LEDs
para mostrar el estado del MedidorE.
 La tarjeta de desarrollo debe estar lista para ser utilizada directamente sin necesidad de
hacer un circuito impreso adicional, que solo baste con programarla y conectar mediante
cables los demás componentes de hardware para lograr así que la implementación del
MedidorE sea un procedimiento muy sencillo.
Basándose en los anteriores puntos se eligió a la FRDM-K64F de NXP antes Freescale (ver
detalles en Apéndice B.2) para desarrollar el emulador de medidor inteligente MedidorE. Esta
tarjeta presenta un microcontrolador (K64) con una velocidad muy por encima de la necesaria
además de contar con una memoria tipo FLASH. La tarjeta cuenta con todos los periféricos
necesarios para su funcionamiento y rápida puesta en marcha.
Para crear la red de comunicaciones entre los MedidorE y el NodoM es necesario:

 Una red alámbrica multidispositivos para trabajar con un protocolo maestro-esclavos como
el MODBUS.
 Dicha red se desea que use el menor número de hilos posibles, sea robusta ante
interferencias y presente buen comportamiento a distancias de hasta 30 metros.
46
 Para formar esta red se requiere de una tarjeta o módulo que permita una rápida conexión
sin necesidad de crear circuitos impresos adicionales y preferentemente a un muy bajo
costo.
Para cumplir con lo anterior se decidió implementar una red RS485 a dos hilos (ver en Apéndice
A.1) para lo cual se eligió un Módulo RS485 que tiene como base al circuito integrado MAX485
y los periféricos adicionales (ver detalle en Apéndice B.4) necesarios para una conexión rápida
directa a la FRDM-K64F.
En resumen los componentes de hardware utilizados en el MedidorE fueron:
 FRDM-K64F
 Módulo RS485
En la figura 3.1 se muestra un diagrama con los componentes elegidos y su forma de interconexión
entre ellos para crear al MedidorE, se explica también el propósito de cada componente.
Red RS485, un maestro (NodoM), múltiples

esclavos (MedidorE)
Módulo convertidor de UART (3.3Vcc) a

E
RS485
FRDM-K64F emulando a un medidor con

soporte para comandos MODBUS
Figura 3.1. Componentes de hardware del MedidorE implementado en esta tesis
47
La conexión física entre el módulo RS485 y la FRDM-K64F se realiza por comunicación serial.
Finalmente el MedidorE, ya sea solo uno o más se conectarán a un NodoM, la comunicación con
este será mediante la red RS485. En la figura 3.2 se muestra el diagrama esquemático de
conexiones pertinente al MedidorE.
FRDM-K64F
Módulo
Fuente 5Vcc
RS485
Micro
USB 3.3Vcc
G ND P3V3 Vcc
G ND
G ND G ND
A
A Red
B RS485
PTB10 Tx Rx D1 B
PTB11 Rx Tx R0
PTC11 Cont rol DE , RE
Figura 3.2. Diagrama de conexiones del MedidorE
3.1.2 NodoM
Los componentes de hardware utilizados para crear el NodoM mencionado en la sección 2.5.2 se
eligieron con el fin de cumplir con los siguientes puntos, comenzando con el dispositivo
programable:
 Al igual que con el MedidorE se requiere un microcontrolador con una velocidad de

procesamiento preferentemente mayor a los 20 MHz para una rápida ejecución de todas sus
funciones y un rápido procesamiento de los mensajes seriales que recibirá constantemente
tanto del CMD como de los MedidorE, además de contar con una memoria tipo FLASH
con espacio suficiente para almacenar 4,096 bytes de datos aproximadamente.
 También será preferible un microcontrolador integrado en una tarjeta de desarrollo
equipada con todos los periféricos necesarios para su óptimo funcionamiento.
 Es necesario contar con herramientas de programación y depuración que permitan
programar cuantas veces sea necesario y monitorear todas las variables y poder correr cada
línea del código y/o mejorar el programa.
 La tarjeta de desarrollo debe estar lista para ser utilizada directamente sin necesidad de
hacer un circuito impreso adicional, que solo baste con programarla y conectar mediante
cables los demás componentes de hardware para lograr así que la implementación del
NodoM sea un procedimiento muy sencillo.
Al igual que con el MedidorE se eligió a la FRDM-K64F de NXP para desarrollar el NodoM.
48
Por el lado de las comunicaciones NodoM – MedidorE los puntos a cumplir son exactamente los
mismos que los citados en el caso del MedidorE por lo que se eligió el mismo Módulo RS485.
Para las comunicaciones NodoM – CMD se deben de cumplir los siguientes puntos:
 Una red inalámbrica multidispositivos para trabajar con un protocolo maestro-esclavos

como el MODBUS.
 Dicha red se desea que sea punto a punto (no malla) de largo alcance (en el rango de cientos
de metros), sea robusta ante interferencias y errores.
 Para formar esta red se requiere de una tarjeta o módulo que permita una rápida conexión
sin necesidad de crear circuitos impresos adicionales.
 Es deseable que utilice comunicación serial transparente (es decir que se transmitan y
reciban mensajes seriales a través de él sin agregar comandos o datos adicionales) para
facilitar el manejo de datos.
Con base a los puntos anteriores se escogió al Módulo RF1276T (ver detalles en Apéndice B.3),
este módulo integra en su circuito un procesador LoRa fabricado por Semtech (ver Apéndice A.2)
así como un microcontrolador adicional encargado de las configuraciones de la red LoRa y también
de hacer que el uso de este módulo tenga un comportamiento transparente.
Ya elegidos los componentes anteriores se tiene solo un inconveniente en cuanto a la

compatibilidad de voltajes, ya que la FRDM-K64F trabaja a 3.3Vcc mientras que RF1276T trabaja
a 5Vcc. Para dar solución a dicho problema fue necesario la implementación de un Convertidor de
niveles digitales con el cual se hace posible la comunicación serial entre dispositivos que trabajen
a diferentes niveles de voltaje.
En resumen los componentes de hardware utilizados en el NodoM fueron:
 FRDM-K64F
 Módulo RS485
 Módulo RF1276T
 Convertidor de niveles digitales
En la figura 3.3 se muestra un diagrama con los componentes del NodoM y la explicación del
propósito de cada uno.
La interconexión entre el módulo RS485 y la FRDM-K64F se realiza por comunicación serial al

igual que la interconexión entre el módulo RF1276T y la FRDM-K64F con un respectivo
convertidor de niveles digitales entre estos dos últimos. En la figura 3.4 se muestra el diagrama
esquemático pertinente al NodoM.
49
Red LoRa, comunica a un maestro (CMD), con múltiples

esclavos (NodoM)
Módulo RF1276 con radio LoRa tipo nodo
Convertidor de niveles digitales (5 y 3.3 Vcc)
FRDM-K64F corazón del NodoM
Módulo convertidor de UART (3.3Vcc) a RS485
Red RS485, enlazará al maestro (NodoM) con múltiples

esclavos (Medidores)
Figura 3.3. Componentes de hardware del NodoM implementado en esta tesis
50
Convertidor
FRDM-K64F Niveles
Fuente Lógicos
Micro RF1276T
U SB 5Vcc
P5V_U SB HV
3.3Vcc 5Vcc
P3V3 LV VCC
Módulo RS485 G ND G ND
G ND G ND G ND G ND
Ant ena
3.3Vcc
Vcc P3V3
Tx
G ND
G ND
G ND PTB11 Rx RX0 RX1 TXD
Tx Rx RXD
A PTB10 TX1 TX0
A
B Rx Tx PTD3
B D1
Tx Rx PTD2
R0
Cont rol PTD1
DE , RE
Figura 3.4. Diagrama de conexiones del NodoM
3.1.3 CMD
Los componentes de hardware utilizados para crear el CMD mencionado en la sección 2.5.3 se
eligieron con el fin de cumplir con los siguientes puntos, comenzando con el dispositivo
programable:
 Para este caso el dispositivo debe ser capaz de ejecutar un sistema operativo que permita
la ejecución de múltiples tareas en tiempo real y de forma simultánea, por lo que más que
un microcontrolador se debe pensar en una computadora con un procesador independiente,
memoria RAM, unidad de almacenamiento masivo y puertos estandarizados con soporte
del protocolo de red TCP/IP.
 Dicha computadora será el corazón del CMD y debe ejecutar desde el arranque programas
de servidor FTP y VNC para el acceso remoto y el monitoreo de archivos.
 También ejecutarán de forma simultanea e indefinida a los programas de monitoreo y
datalogger.
 Deseable una computadora lo más pequeña y económica posible, que además no requiera
de muchos periféricos adicionales.
Se eligió entonces a la Raspberry Pi 2 B (ver detalles en Apéndice B.1) ya que cuenta con todos
los periféricos de hardware necesarios para poder ejecutar un sistema operativo en base Linux en
el cual se pueden instalar y configurar para correr permanentemente los programas servidor FTP y
servidor VNC requeridos, estas aplicaciones harán uso del protocolo TCP/IP por medio del puerto
Ethernet incluido en la tarjeta. Además esta tarjeta cuenta con lo necesario para compilar y
ejecutará los programas de monitoreo y datalogger. Es esta tarjeta la que forma el corazón del
51
CMD y por ende la parte principal de esta tesis que actúa como administrador y sistema de
monitoreo de toda la AMI que se ha propuesto.
Por el lado de las comunicaciones CMD – NodoM los puntos a cumplir son exactamente los
mismos que los citados en el caso del NodoM por lo que se eligió el mismo Módulo RF1276T.
Para los componentes anteriores se tiene mismo problema en cuanto a los niveles de voltaje; la
Raspberry Pi trabaja a 3.3Vcc mientras que RF1276T trabaja a 5Vcc. Para dar solución se
implementó el mismo Convertidor de niveles digitales.
Para poder hacer el registro de datos con la mejor precisión de tiempo posible es necesario tener
una referencia de tiempo fija, en pocas palabras un reloj el cual proporcione todo el tiempo la hora
y fechas exactas. La Raspberry Pi normalmente obtiene estos datos conectándose a internet pero
para este caso de AMI en específico no se puede depender de una conexión a internet, por lo que
el problema se puede solucionar agregando un reloj en tiempo real (RTC por sus siglas en inglés).
El componente elegido entonces fue el Módulo DS3231 (ver detalles en Apéndice B.5) el cual
además cuenta con una batería de respaldo para mantener la fecha y hora aun cuando la Raspberry
Pi sea des energizada.
En resumen los componentes de hardware para formar al CMD son:
 Raspberry Pi 2
 Convertidor de niveles digitales
 Módulo DS3231
 Módulo RF1276T
En la figura 3.5 se muestra un diagrama a bloques con los componentes del CMD y una breve
explicación.
La interconexión entre el módulo RF1276T y la Raspberry Pi 2 se realiza por comunicación serial

pero entre estos dos componentes se necesita un acoplamiento de voltajes realizado por el
Convertidor. La comunicación con el DS3231 se realiza por el puerto i2c disponible en la
Raspberry Pi, la conexión es directa. Finalmente para conectarse al Sistema Administrador la
Raspberry pi cuenta con una terminal Ethernet mediante la cual se puede conectar a una red LAN
y permitir así el funcionamiento como servidor bajo los protocolos TCP/IP. En la figura 3.6 se
muestra el diagrama esquemático con las conexiones correspondientes del CMD.
52
Red LAN del Sistema Administrador
Conexión TCP/IP, Ethernet
Raspberry Pi 2 funcionando como corazón del CMD
Convertidor de niveles digitales (permite comunicación entre

5 y 3.3 Vcc)
Módulo RTC el cual mantendrá la fecha y la hora aun cuando

se des energice la Raspberry pi, se accede a este por
comunicación i2c
Módulo RF1276 con radio LoRa tipo central
Red LoRa, un radio central (CMD), múltiples nodo

(NodoM)
Figura 3.5. Componentes de hardware del CMD implementado en esta tesis
Figura 3.6. Diagrama esquemático de conexiones del CMD
53
3.1.4 Sistema Administrador

El Sistema Administrador mencionado en la sección 2.5.4 requirió que sus componentes de
hardware cumplieran con los siguientes puntos, comenzando con el dispositivo que permitirá la
conexión remota:
 Se necesita un dispositivo que permita una conexión remota de alta velocidad y seguridad
de datos, el protocolo de red deberá ser TCP/IP al cual se tendrá acceso a través de un
puerto Ethernet para hacerlo completamente compatible con la Raspberry Pi.
 Este dispositivo deberá ser capaz de formar una red LAN (ver en sección 2.4.2) para que
se pueda acceder y administrar a uno o más CMD desde una computadora personal.
 Dicho dispositivo deberá ser de fácil acceso y configuración para fines prácticos en este
proyecto, así como económico.
Analizado lo anterior el dispositivo debía de ser un enrutador o router LAN, al que se tuvo acceso
y se utilizó finalmente fue un HG8245H de la marca Huawei (ver detalles en Apéndice B.7).
Finalmente el último componente necesario en el Sistema Administrador así como en esta AMI
será la interfaz hombre máquina mediante la cual el administrador (humano) tendrá acceso y
completo control de toda la AMI. Esta deberá de ser una Computadora Personal (ver
especificaciones necesarias en Apéndice B.8), mediante esta computadora se accesará en tiempo
real al CMD pudiendo tener así control total para detener o correr los programas de datalogger y/o
monitoreo, también permite el acceso a los archivos de medición y de configuración.
En resumen los componentes que conforman al Sistema Administrador son:
 Computadora Personal
 Router LAN
En la figura 3.7 se muestra el diagrama a bloques del Sistema Administrador propuesto en esta
tesis.
En este caso no se necesita un diagrama de conexiones como en los anteriores, para ver detalles
de conexiones físicas ver sección 3.3.4.
54
Computadora personal desde la cual el usuario tendrá

acceso y control total de la AMI
Conexión TCP/IP, Ethernet o Wi-Fi
Router doméstico Huawei HG8245H el cual conforma la

Red de Área Local (LAN) con la que se accesa a la AMI
Conexión TCP/IP, Ethernet
CMD y resto de la AMI
Figura 3.7. Componentes de hardware del Sistema Administrador de la AMI propuesta
3.2 Sistemas de comunicación dentro de la AMI propuesta

A lo largo de este capítulo se ha ido explicando la función de cada elemento de esta AMI, así como
también su composición de hardware y los medios físicos de comunicación utilizados para
comunicarse entre unos y otros. Pero para conformar un sistema de comunicación se requiere
también de un protocolo de comunicaciones, el cual es el encargado de definir la manera de
interactuar entre dos dispositivos a través de un mismo medio físico. En la figura 3.8 se muestran
los diferentes medios físicos así como los protocolos de comunicación que hacen interactuar a los
componentes usados en esta AMI. Se puede ver dicha relación entre dispositivos, medios físicos y
protocolos de comunicación de manera resumida en la tabla 3.1.
Tabla 3.1. Medios físicos de comunicación y protocolos entre las diferentes etapas de la AMI
Dispositivo Medio físico Protocolo Dispositivo
MedidorE RS485 MODBUS NodoM
LoRaWAN (solo entre los radios,
NodoM LoRa transparente) CMD
MODBUS
CMD Ethernet TCP/IP (FTP, VNC) Sistema Administrador
55
Red
CMD_2 RS485
Medidor_1
NodoM_2 (Esclavo_2)
(Maestro)
(Nodo_2)
Red
CMD_4 LoRa
(Esclavo_1)
(Repetidor)
CMD_1 01 Medidor_2
(Esclavo_3)
(Central_1)
192.168.100.x
(Maestro)
(FTP Servidor)
CMD_3 (VNC Servidor)
Red
NodoM_3 RS485
(Nodo_3)
(Maestro) Medidor_3
(Esclavo_1)
(Repetidor) (Esclavo2)
Ethernet
Red
192.168.100.1 RS485 Medidor_4
(Esclavo_2)
192.168.100.2 Sistema
NodoM_4
(FTP Cliente)
(VNC Cliente)
Administrador
(Nodo_4)
(Maestro)
(Esclavo_1) Medidor_5
(Repetidor)
(Esclavo_3)
Medidor_6
TCP/IP
(Esclavo_4)
LoRa
MODBUS
Figura 3.8. Interacción entre los diferentes protocolos y medios físicos de comunicación de la AMI
3.2.1 Comunicación MedidorE - NodoM

La comunicación entre el NodoM y el MedidorE se realiza por medio de una red RS485 operando
bajo el protocolo de comunicaciones MODBUS, donde los MedidorE’s actuarán siempre como
esclavos mientras que el maestro puede ser directamente el NodoM o el CMD.
Cuando el NodoM es el maestro MODBUS envía directamente el mensaje de petición a través de
la red RS485 esperando que el MedidorE esclavo deseado responda.
Cuando el CMD es el maestro MODBUS y pretende comunicarse con algún Medidor, este deberá
dirigirse primero al NodoM a través del número de radio LoRa pertinente (ver ejemplo en sección
5.1.3), el NodoM recibe el mensaje y lo redirecciona a través de su red RS485 para que pueda
llegar hasta el Medidor deseado por lo que en este caso el NodoM se comportará como un simple
intermediario entre el CMD y el Medidor.
56
3.2.2 Comunicación NodoM - CMD

La comunicación entre el CMD y el NodoM se realiza por medio de una red de radios LoRa (medio
Físico), donde el radio conectado al NodoM está trabajando en modo nodo o esclavo (dentro de la
red LoRa), mientras que el radio conectado al CMD será el configurado como central o maestro.
La red LoRa maneja su propio protocolo de comunicaciones llamado LoRaWAN pero a diferencia
de MODBUS no se tiene interacción directa con este protocolo ya que todo lo ejecuta un
microcontrolador que forma parte del módulo RF1276T, el usuario solo tendrá que utilizar
trasmisión de datos en forma serial y la dirección del radio al que se quiere dirigir un mensaje. Los
propios RF1276T por medio de LoRaWAN se encargarán de transmitirla del radio transmisor hasta
el radio receptor y este último generará el mismo mensaje a través de una salida a puerto serial,
haciendo lo que se llama transmisión transparente.
3.2.3 Comunicación CMD – Sistema Administrador

Como se explicó en la sección 3.1.4 el Sistema Administrador está conformado por una red
informática y una o más computadoras, por lo que el enlace entre el CMD y el Sistema
Administrador se realizará también por medio de una conexión del tipo TCP/IP, de entre las cuales
pueden existir como medio físico conexiones de fibra óptica, Wi-Fi o Ethernet principalmente,
siendo esta última la utilizada en este proyecto. En el Sistema Administrador de esta tesis se
considera que una computadora personal será el dispositivo final desde el cual se ingresa,
monitorea y modifica toda la AMI, esta computadora accede al o a los CMD pasando previamente
por un equipo intermediario mejor conocido como router (enrutador si se traduce al español) el
cual también se considera parte del medio físico de comunicaciones ya que este router es el que
proporciona los puertos de conexión RJ45 (mejor conocidos como Ethernet) y/o la señal Wi-Fi
para interconectar a la computadora personal con el resto de la AMI.
Cuando se habla de TCP/IP se habla de un gran protocolo de comunicaciones estandarizado e

internacional el cual a su vez involucra muchos protocolos diferentes en su capa de aplicación
(interacción con el usuario final). Es utilizado en esta tesis el protocolo FTP (miembro de la familia
TCP/IP) como medio de acceso a los archivos almacenados en el CMD, siendo el CMD el servidor
FTP y la computadora remota con la que se accederá a los datos un cliente FTP.
También se hace uso de VNC como medio de acceso remoto al sistema operativo del CMD. VNC
más que un protocolo integrante de la familia TCP/IP es un programa que hace uso de puertos TCP,
nuevamente el CMD será el servidor mientras que la computadora remota con la que se accederá
será el cliente VNC.
57
3.3 Diagramas de conexiones de hardware dentro de los

dispositivos de la AMI
Se mencionó la arquitectura propuesta para cada componente de esta AMI así como también cada
uno de los componentes de hardware implicados en cada etapa, en la siguiente sección se detalla
gráficamente el diagrama de conexiones entre estos.
3.3.1 Diagrama de conexiones para Medidor

Para implementarla el Medidor se usaron: una tarjeta FRDM-K64F y un módulo RS485, en la
figura 3.9 se muestra el diagrama de conexiones entre ambos y en la tabla 3.2 se resumen los pines
relacionados en ambos componentes:
Medidor Red RS485
Fuente 5vcc
USB
Figura 3.9. Diagrama de conexiones de Medidor
Tabla 3.2. Conexiones entre la FRDM-K64F y el módulo RS485

FRDM-K64F Módulo RS485
Nombre pin Descripción Nombre pin Descripción
J3-8 (P3V3) Salida 3.3Vcc ↔ VCC Entrada 3.3Vcc
J3-12 (GND) Tierra ↔ GND Tierra
J4-6 (PTB10) Serial Tx ↔ D1 Serial Rx
J4-8 (PTB11) Serial Rx ↔ R0 Serial Tx
↔ DE Control transmisión
J4-10 (PTC11) Control RS485
↔ RE Control recepción
58
3.3.2 Diagrama de conexiones para NodoM

Para implementarla el NodoM se usó una FRDM-K64F, un módulo RS485, un convertidor de
niveles lógicos y un módulo RF1276T. En la figura 3.10 se muestra el diagrama de conexiones y
en las tablas 3.3, 3.4 y 3.5 se resumen los pines relacionados en todos los componentes.
Red LoRa
NodoM
Fuente 5vcc
USB
Red RS485
Figura 3.10. Diagrama de conexiones de NodoM
59
Tabla 3.3. Conexiones entre la FRDM-K64F y el Convertidor de niveles lógicos

FRDM-K64F Convertidor de niveles lógicos
J3-8 (P3V3) Salida 3.3Vcc ↔ LV Entrada 3.3Vcc
J3-10 (P5V_USB) Salida 5Vcc ↔ HV Entrada 5Vcc
J4-6 (PTB10) Serial Tx ↔ TX1 Serial Tx, 3.3Vcc
J4-8 (PTB11) Serial Rx ↔ RX0 Serial Rx, 3.3Vcc
Tabla 3.4. Conexiones entre la FRDM-K64F y el Módulo RS485

FRDM-K64F Módulo RS485
J3-4 (P3V3) Salida 3.3Vcc ↔ VCC Entrada 3.3Vcc
↔ DE Control transmisión
J2-12 (PTD1) Control RS485
↔ RE Control recepción
J2-10 (PTD3) Serial Rx R0 Serial Tx
J2-8 (PTD2) Serial Tx D1 Serial Rx
Tabla 3.5. Conexiones entre el Convertidor de niveles lógicos y el RF1276T

Convertidor de niveles lógicos RF1276T
HV Entrada 5Vcc ↔ VCC Entrada 5Vcc
GND Tierra ↔ GND Tierra
RX0 Serial Rx, 5Vcc ↔ TXD Serial Tx
TX1 Serial Tx, 5Vcc ↔ RXD Serial Rx
3.3.3 Diagrama de conexiones para CMD
Para la implementación del CMD se utilizaron como componentes: una Raspberry Pi 2, un

Módulo DS3231, un Convertidor de niveles digitales y un Módulo RF1276T, el diagrama de
conexiones se aprecia en la figura 3.11 mientras que las conexiones entre los componentes se
describen en las tablas 3.6, 3.7 y 3.8.
60
Red LoRa
CMD
Red LAN TCP/IP
Fuente 5vcc
USB
Figura 3.11. Diagrama de conexiones de CMD
Tabla 3.6. Conexiones entre la Raspberry Pi 2 y el Módulo DS3231

Raspberry Pi 2 Módulo DS3231
1 (3V3) Salida 3.3Vcc ↔ VCC Alimentación (3.3-5)Vcc
3 (GPIO2, SDA I2C) Línea SDA del puerto i2c ↔ SDA Línea SDA del puerto i2c
5 (GPIO3, SCL I2C) Línea SCL del puerto i2c ↔ SCL Línea SCL del puerto i2c
7( Ground) Tierra ↔ GND Tierra
61
Tabla 3.7. Conexiones entre la Raspberry Pi 2 y el Convertidor de niveles lógicos

Raspberry Pi 2 Convertidor de niveles lógicos
4 (5V) Salida 5Vcc ↔ HV Entrada 5Vcc
8 ( GPIO14, UART_TXD ) Serial Tx ↔ TX1 Serial Tx, 3.3Vcc
10 (GPIO15, UART_RXD) Serial Rx ↔ RX0 Serial Rx, 3.3Vcc
14 (Ground) Tierra ↔ GND Tierra
17 (3V3) Salida 3.3Vcc ↔ LV Entrada 3.3Vcc
Tabla 3.8. Conexiones entre el Convertidor de niveles lógicos y el RF1276T

Convertidor de niveles lógicos RF1276T
HV Entrada 5Vcc ↔ VCC Entrada 5Vcc
GND Tierra ↔ GND Tierra
RX0 Serial Rx, 5Vcc ↔ TXD Serial Tx
TX1 Serial Tx, 5Vcc ↔ RXD Serial Rx
3.3.4 Diagrama de conexiones para Sistema Administrador
Posiblemente este último diagrama de conexiones sea el menos detallado pero en realidad solo
pretende dar una idea del tipo de conexión entre un componente y otro, las conexiones en puertos
o pines en específico no es necesaria en este caso (ver figura 3.12).
Figura 3.12. Diagrama de conexiones del Sistema Administrador
62
Capítulo 4: Descripción del

Software Implementado
En esta sección se explicará de forma detallada como es que se desarrolló todo el software,
abarcando tanto los programas desarrollados como las configuraciones de hardware (Raspberry Pi
y radios LoRa) y como se van relacionando unos con otros.
Este capítulo describe la programación y configuración de los componentes que forman la AMI y
se divide en los puntos siguientes:
 Programa MedidorE
 Programa NodoM
 Programa datalogger
Respecto a los programas se explica primero en que plataforma se desarrollaron y corrieron, las
configuraciones previas de los componentes utilizados por el programa, el lenguaje de
programación utilizado y posteriormente se anexan cada una de las funciones con su lista de
variables y los diagramas de flujo correspondientes, todo con su respectiva explicación y forma de
desarrollo paso por paso.
En cuanto a las configuraciones de hardware se explica también el software utilizado, su objetivo

y todos los pasos necesarios que se llevaron a cabo para que pudiera funcionar de la forma deseada.
63
4.1 Programa MedidorE
La programación se realizó en la paquetería “CodeWarrior” versión 10.6.4 de NXP, el lenguaje de

programación utilizado fue C y se hizo uso de una herramienta llamada “Processor Expert” (ver
configuraciones en Apéndice C.1) la cual facilita el uso de los componentes del microcontrolador.
Las tareas programadas en el MedidorE son:
1. El MedidorE trabajará bajo el protocolo de comunicaciones MODBUS actuando como

esclavo y teniendo por defecto el número 255, el cual podrá ser cambiado posteriormente
mediante instrucciones MODBUS (ver sección 5.1.2). El set de instrucciones MODBUS y
su adecuada interpretación es parte fundamental de las funciones de este programa.
2. La comunicación del MedidorE con el NodoM se realizará por un puerto serial conectado
a una interfaz RS485, este puerto e interfaz serán administrados por este programa.
3. Se usará una función generadora de números aleatorios rand( ) propia del lenguaje C, para
estar generando mediciones ficticias dentro de ciertos rangos de los principales parámetros
eléctricos que son medidos por un medidor real. Valores instantáneos de: voltaje, corriente,
frecuencia, factor de potencia, THD. Valores acumulados de: Potencia Activa y Potencia
Reactiva.
4. Se tendrán los datos de mediciones obtenidos (inventados) disponibles en un espacio de
memoria RAM llamado registro (ver en tabla 4.1) al cual se podrá acceder mediante
instrucciones MODBUS.
5. Hará el respaldo en una memoria no volátil (en este caso memoria FLASH) de las
mediciones acumulativas como KWh y KVArh cada minuto.
6. El programa MedidorE estará continuamente a la espera de un mensaje de verificación por
parte del NodoM (el cual se portará en ese momento como maestro MODBUS), si no
recibe dicho mensaje el MedidorE se desactivará (desconectando al usuario de la red
eléctrica).
7. El MedidorE simulará la conexión o desconexión del usuario a la red eléctrica por medio
de un LED rojo el cual será controlado por instrucciones MODBUS.
64
Tabla 4.1. Variable Registro donde se leerán y/o escribirán datos usando los comando MODBUS.
Aquí se guardan los valores de los parámetros eléctricos obtenidos (ficticios) por el MedidorE.
REGISTROS QUE OCUPA DESCRIPCIÓN Y RANGOS DE VALORES QUE SE
PARÁMETRO
DENTRO DEL MEDIDOR PUEDEN ALMACENAR
El número de serie de cada medidor debe ser único,
Número de Serie del
{0}…{15} en CFE es alfanumérico de 6 dígitos, en esta tesis se
MedidorE
manejó de 10, aunque tiene espacio para 16
Número de esclavo dentro de la red RS485
Número de Esclavo {16}
MODBUS, podrá ser un valor entre 2 y 255
Estado (conectado o
{17} 0 = desconectado, 1 = conectado
desconectado)
Voltaje {18}{19}{20}{21} Generará valores entre 110.00 y 130.99 Vac
Corriente {22}{23}{24}{25} Generará valores entre 0.00 y 30.99 A
Frecuencia {26}{27} Generará valores entre 59.00 y 60.99 Hz
Factor de Potencia {28}{29} Generará valores entre 65.00 y 99.99 %
Distorsión Armónica Total {30}{31} Generará valores entre 0.00 y 20.99 %

Periodo de tiempo en el que se estarán tomando las
Tiempo de adquisición de
{32}{33} mediciones por parte del CMD:
datos
0 a 23 horas, 0 a 59 minutos
Mostrará valores acumulados entre 0.00 y
KWh {34}{35}{36}{37}
999999.99 KWh
Mostrará valores acumulados entre 0.00 y
KVArh {38}{39}{40}{41}
999999.99 KVArh
THD promediada (o
máxima) sobre tiempo de {42}{43} Generará valores entre 0.00 y 20.99 %
adquisición de datos
Registros no definidos
{44}……{82}
multipropósitos
Registros donde el NodoM estará escribiendo el
Registros de verificación {83}……{99} código de verificación para mantener activo al
MedidorE
Los registros 32 y 33 almacenarán el periodo de tiempo en el que el concentrador CMD estará

tomando los datos de medición, es importante que el medidor conozca este dato para que este
calculando valores picos (máximos y mínimos) de una o más variables, así como también
promedios y alarmas solo durante ese periodo de tiempo, así para la siguiente adquisición de datos
obtendrá un nuevo valor pico. En este MedidorE el único valor pico que se estará actualizando
durante ese periodo es el THD y se registrará en los registros 42 y 43 solo para ejemplificar.
65
4.1.1 Funciones programadas en el MedidorE

Las siguientes funciones han sido programadas en la tarjeta FRDM-K64F, y básicamente son las
responsables de hacer funcionar este medidor emulado.
f_main( ) Es la función principal que llamará a las siguientes funciones: La función f_reset() es
llamada desde aquí solo cuando se encuentre activa. La función f_inicia_medidor() se
ejecutará solo una vez cada que el microcontrolador sea reiniciado. La función
f_medidor( ) se ejecutará permanentemente.
f_reset( ) Esta función solo es usada en la etapa de pruebas y se encarga de poner todas las
variables en cero, incluidas las acumulativas guardadas en la memoria FLASH.
También pone el número de esclavo del medidor en 255. Normalmente esta función
esta comentada en el código para que no sea ejecutada más que en casos necesarios.
f_inicia_medidor( ) Cada vez que el MedidorE se apague todos los datos de mediciones que están
en la memoria RAM se perderán. Las variables como KWh y KVArh deben de
conservarse por lo que están siendo continuamente guardadas en la memoria FLASH.
Cuando el MedidorE sea reiniciado se ejecutará esta función con el fin de cargar los
valores previamente guardados en la memoria FLASH.
f_medidor( ) Es la función más importante en este programa ya que es la encargada de generar

todos los valores aleatorios dentro de ciertos rangos para poder emular a un medidor
real. También estará al pendiente si algún mensaje ha sido recibido por el NodoM
mediante la bandera modbus_check (si es así llama a la función f_MODBUS( ) ), y
checará cada cierto tiempo que se haya recibido el código de verificación por parte
también del NodoM para que pueda seguir funcionando. Hará los respaldos de las
mediciones en la memoria FLASH cada minuto.
f_MODBUS( ) Cuando un mensaje ha sido enviado completo por el NodoM será llamada esta
función. Primero desactivará al timmer TI1 (temporizador de espera de datos usado en
el evento RS485_OnRxChar( ) ). Posteriormente manda a analizar el mensaje recibido
mediante la función f_analizar_mensaje( ), si el mensaje es correcto, se forma y envía
el mensaje de respuesta con las funciones f_formar_replica( ) y f_enviar_replica( ).
Finalmente resetea la bandera modbus_check.
f_analizar_mensaje( ) Esta función analizará les mensajes recibidos por el puerto serial llamado
RS485 (provenientes del NodoM) para checar su CRC llamando a f_calcular_crc( ),
también verifica el correcto número de esclavo. Finalmente verifica el número de
instrucción (instrucción MODBUS a ejecutar); si es la 0x03 llama a f_lee_multi( ), si
es la 0x06 llama a f_escribe_uno( ), si es la 0x10 llama a f_escribe_multi( ) y si no es
ninguna genera el error 0x01.
66
f_calcular_crc( ) En esta función se ejecuta el algoritmo para el cálculo de CRC MODBUS a 16

bits. El resultado se guarda en los bytes crc_a y crc_b.
f_lee_multi( ) Instrucción MODBUS con la que se pueden leer dos o más datos de la variable
registro.
f_escribe_uno( ) Instrucción MODBUS con la que se puede escribir un valor en una sola localidad
de la variable registro.
f_escribe_multi( ) Instrucción MODBUS con la que se pueden escribir dos o más datos de la
variable registro.
f_formar_replica( ) Esta función se encarga de formar el mensaje_replica el cual es el que será

enviado como respuesta MODBUS al NodoM.
f_enviar_replica( ) Función encargada de enviar el mensaje_replica por el puerto serial RS485

y controla el modo (transmitir o recibir) del chip RS485.
TI1_OnInterrupt( ) Evento del timmer TI1 llamado cada 1ms usado para decrementar la variable
timmer, cuando esta llegue a cero se habrán contado 5ms desde el ultimo byte recibido
por RS485_OnRxChar( ), esto significará que se ha terminado de recibir un mensaje
del NodoM y se indica con la bandera modbus_check.
RS485_OnRxChar( ) Evento llamado cada que se recibe un byte por el puerto serial RS485, irá
formando el mensaje_recibido, adicionalmente se encarga de activar el timmer TI1 y
pondrá a la variable timmer=5 con el fin detectar cuando un mensaje ha sido recibido
por completo.
RS485_OnTxChar( ) Evento usado para transmitir byte por byte un mensaje a través del puerto
serial RS485, una vez que se ha comenzado a enviar dicho mensaje este evento será
llamado continuamente hasta haber enviado la cantidad de: longitud bytes.
A continuación se explican cada una de las funciones comenzando con una breve descripción,
siguiendo con una lista donde se muestran las variables utilizadas por dicha función (las de
recuadro verde son variables globales y las de recuadro amarillo son variables locales) y finalmente
su correspondiente diagrama de flujo con una explicación más detallada. Para comparar con el
programa escrito en “CodeWarrior” se recomienda ver las líneas de código en el Apéndice C.2.
67
4.1.1.1 f _main( )
Esta es la función principal encargada de:

 Resetear (solo en caso de pruebas) los registros almacenados en la memoria FLASH.
 Inicializar al MedidorE con los valores guardados anteriormente en la memoria FLASH.
 Ejecutar continuamente el programa principal de mediciones.
Tabla 4.2. Diagrama de flujo y explicación de f_main

Esta es la función principal.
La función f_reset( ) se encargará de limpiar todos

los registros, solo se usará para pruebas, por eso se
pone con líneas punteadas.
Al encender el medidor se ejecutará la función

f_inicia_medidor( ) la cual cargará los valores de
la memoria FLASH anteriormente registrados.
Se crea un bucle infinito que continuamente estará

ejecutando la función f_medidor( )
4.1.1.2 f_reset( )
Esta función tiene el objetivo de:
 poner en ceros todos los registros que acumulan mediciones (del 16 al 43),
 poner al medidor como el esclavo 255,
 el Número de Serie se conservará.
Solo será ejecutada mientras se realizan pruebas, es la única que deberá ser activada modificando
el programa principal, ya que ha sido comentada. La idea es que las variables acumulativas como
KWh y KVArh nunca deberían ser reseteadas en un medidor salvo casos como la ejecución de
pruebas.
Tabla 4.3. Variables locales usadas por f_reset

-Número de Serie del medidor
-Arreglo inicializado con ceros
-Dirección de memoria FLASH donde
se guardan los datos medidos, el cual
será reseteado
68
Tabla 4.4. Diagrama de flujo de f_reset
-En este bucle se guardan los 16

dígitos correspondientes al Número
de Serie del medidor en los
primeros 16 bytes (del 0 al 15) de
vector_grabar.
-vector_grabar[16]=255 será el
número esclavo por defecto para el
medidor.
-En este bucle se resetean (ponen a

cero) los siguientes bytes (del 18 al
43) de vector_grabar.
-Primero se borra el sector de

memoria FLASH donde se
almacenan los datos.
-Después se graba en ese mismo
sector la variable vector_grabar.
4.1.1.3 f _inicia_medidor( )
Esta función leerá de la memoria FLASH todas las variables almacenadas previamente (ver sección
4.1.1.4 f_medidor()) y las copiará en la variable registro. La variable registro es un arreglo que
está en la memoria RAM y será en donde se están guardando continuamente las mediciones así
como el proceso de lectura y escritura con las instrucciones MODBUS. Las variables utilizadas
por esta función son:
Tabla 4.5. Variables globales y locales usadas por f_inicia_medidor

-Variable global utilizada como registros de lectura y
escritura MODBUS
-Variables auxiliares para bucles y para guardar datos
-Dirección de memoria FLASH donde se guardan los
datos medidos, el cual será reseteado
69
Tabla 4.6. Diagrama de flujo de f_inicia_medidor
-Se inicia un bucle para leer byte por

byte los datos almacenados en la
memoria FLASH a partir de la
dirección 0xF000.
-Los datos se almacenan en Dato y
posteriormente se almacena en la RAM
en la variable global registro.
-Bit ENEABLE=0 para poner en modo

escucha al chip RS485.
-En base a los datos antes leídos se

recalculan las variables: KWh, KVArh,
Wh y Varh, y se guardan también en
registro.
4.1.1.4 f _medidor( )
Esta es la función principal dentro del MedidorE encargada de crear todos los valores ficticios de
un medidor digital. Los valores para este medidor son generados por medio de la función de valores
aleatorios rand() la cual genera un valor entero aleatorio entre 0 y 2^32, si es seguida por la
expresión “%N” (operación módulo del valor N), genera números aleatorios entre 0 y N-1, de esta
manera podrá delimitarse el rango máximo de dichos valores aleatorios. Por ejemplo si se tiene la
siguiente expresión: x = rand( )%100, x tomará un valor entre 0 y 99.
Para cada parámetro eléctrico se delimitaron rangos de valores diferentes, los cuales se explican a
continuación junto con las ecuaciones necesarias para formarlos así como la forma en que se
almacenan en la variable registro:
Voltaje: El rango para el voltaje instantáneo ficticio es de 110.00 a 130.99 Vac, este será
almacenado en los registros 18, 19, 20 y 21 y se formará de la siguiente manera:
registro[18] = 0, registro[19] = 1, registro[20] = 110 + rand()%21, registro[21] = rand()%100
Vac = (registro[19]*100) + registro[20] + (registro[21]/100) (4.1)
Corriente: El rango para la corriente instantánea ficticia es de 0 a 30.99 A, esta será almacenada en
los registros 22, 23, 24 y 25 y se formará de la siguiente manera:
registro[22] = 0, registro[23] = 0, registro[24] = rand()%31, registro[25] = rand()%100
70
Iac = registro[24] + (registro[25]/100) (4.2)
Frecuencia: El rango para la frecuencia ficticia va de los 59.00 a 60.99 Hz, este será almacenado
en los registros 26 y 27 y se formará de la siguiente manera:
registro[26] = 59 + rand()%2, registro[27] = rand()%100
f = registro[26] + (registro[27]/100) (4.3)
Factor de Potencia: El rango para el factor va de 65.00 a 99.99 %, este será almacenado en los
registros 28 y 29 y se formará de la siguiente manera:
registro[28] = 99 - rand()%35, registro[29] = rand()%100
fp = registro[28] + (registro[29]/100) (4.4)
Distorsión Armónica Total: El rango para la distorsión armónica total (THD) va de 0 a 20.99 %,
este será almacenado en los registros 30 y 31 y se formará de la siguiente manera:
registro[30] = rand()%21, registro[31] = rand()%100
THD = registro[30] + (registro[31]/100) (4.5)
Para generar las potencias activas y reactivas acumulativas se utilizan ecuaciones que trabajan con
valores enteros sin manejo de punto flotante, es decir cualquier fracción decimal resultante en las
divisiones no será considerada y por lo tanto se perderá.
Potencia Activa Acumulada: Para generarla el MedidorE generará primero un valor de potencia
activa instantánea denominado “watt”, este valor es generado de forma aleatoria cada
minuto tomando valores entre 0 y 4000 watts.
watt = rand()%4001 (4.6)
este valor de watt deberá ser visualizado como una muestra sobre unidad de tiempo, al ser
generado cada minuto puede considerarse watt/minuto, pero en este caso la unidad de
tiempo deseada es la hora por lo que se deberá entonces dividir entre 60 (el resultado queda
sin valores decimales). Entonces para generar watt/hora Wh:
Wh = watt/60 (4.7)
Al tratarse de potencia acumulativa entonces se deberá estar sumando al valor anterior cada
nuevo minuto, por lo tanto:
Wh = Wh + (watt/60) (4.8)
Ahora la unidad que se pretende crear es el KW/hora, para llegar a esta se debe entonces
dividir entre 1000 (nuevamente se perderán los decimales con la división):
71
KWh = Wh/1000 (4.9)
Para tener una mayor precisión no sería suficiente solo considerar los KW/hora por lo que
también se consideran dos décimas después del punto, debido a que se perdieron en la
ecuación anterior por tratarse solo de valores enteros, las decimales deben calcularse y
guardarse en otra variable llamada dKWh, es decir:
dKWh = (Wh – (KWh*1000))/10 (4.10)
Después de las operaciones anteriores ya se habrá generado un valor de potencia activa el

cual constantemente (cada minuto) será incrementado, este valor podrá tomar un valor
desde 0 hasta 999999.99 KWh, se usarán los registros 34, 35 y 36, para guardar cada uno
dos cifras de la variable KWh, y el registro 37 para guardar las dos cifras decimales
contenidas en dKWh. Los detalles al momento de guardar estos datos en los registros se
muestran a continuación:
registro[34] = KWh/10000, registro[35] = (KWh –(registro[34]*10000))/100

registro[36] = KWh – (registro[34]*10000)) – (registro[35]*100)
registro[37] = dKWh
Finalmente puede verse la potencia activa del MedidorE por medio de la siguiente
ecuación:
P = (registro[34]*10000) + (registro[35]*100) +
registro[36] + (registro[37]/100) (4.11)
Potencia Reactiva Acumulada: Para la potencia reactiva acumulativa el MedidorE generará

primero un valor de energía reactiva instantánea denominado “VAr”, este valor depende de
la potencia activa y del factor de potencia, o visto de otro modo de la relación angular
“rel_ang” entre la potencia activa y reactiva, es decir del parámetro tanΦ (ver ecuación
(1.12) en la sección 2.1.8). Se divide entre 100 el factor de potencia ya que se estaba
tomando en forma de porcentaje.
fp
𝐫𝐞𝐥_𝐚𝐧𝐠 = 100 ∗ tan (cos −1 (100)) (4.12)
Para el caso del MedidorE esta relación angular podría tomarse del valor del factor de
potencia pero para efectos de practicidad también decidió por que se creará de manera
aleatoria, tomando valores de 1 a 30, considerando que Q valga el 30% de P como máximo.
rel_ang = 1 + rand()%31 (4.13)
Con este valor de relación angular y el de la potencia activa creado previamente en watt se
crea la variable VAr. Se divide entre 100 ya que rel_ang relacionará solo un porcentaje de
la potencia activa watt:
VAr = (watt*rel_ang)/100 (4.14)
72
Este valor de VAr deberá ser visualizado como una muestra sobre unidad de tiempo, al ser
generado cada minuto puede considerarse VAr/minuto, pero en este caso la unidad de
tiempo deseada es la hora por lo que se deberá entonces dividir entre 60 (el resultado queda
sin valores decimales). Entonces para generar VAr/hora VArh:
VArh = VAr/60 (4.15)
Al tratarse de potencia acumulativa entonces se deberá estar sumando al valor anterior cada
nuevo minuto, por lo tanto:
VArh = VArh + (VAr /60) (4.16)
Ahora la unidad que se pretende crear es el KVAr/hora, para llegar a esta se debe entonces
dividir entre 1000 (nuevamente se perderán los decimales con la división):
KVArh = VArh/1000 (4.17)
Para tener una mayor precisión no sería suficiente solo considerar los KVAr/hora por lo que
también se consideran dos décimas después del punto, debido a que se perdieron en la
ecuación anterior por tratarse solo de valores enteros, las decimales deben calcularse y
guardarse en otra variable llamada dKVArh, es decir:
dKVArh = (VArh – (KVArh*1000))/10 (4.18)
Después de las operaciones anteriores ya se habrá generado un valor de potencia reactiva

el cual constantemente (cada minuto) será incrementado, este valor podrá tomar un valor
desde 0 hasta 999999.99 KVArh, se usarán los registros 38, 39 y 40, para guardar cada uno
dos cifras de la variable KVArh, y el registro 41 para guardar las dos cifras decimales
contenidas en dKVArh.
registro[38] = KVArh/10000, registro[39] = (KVArh – (registro[38]*10000))/100

registro[40] = KVArh – (registro[38]*10000)) – (registro[39]*100)
registro[41] = dKVArh
Finalmente la potencia reactiva del MedidorE se calcula con la siguiente ecuación:
VAr = (registro[38]*10000) + (registro[39]*100) + (4.19)

registro[40] + (registro[41]/100)
Distorsión Armónica Total máxima detectada entre cada toma de datos: En un medidor real los
valores pico se obtienen en base a las mediciones instantaneas que son constantemente
monitoreadas para detectar si el valor actual es mayor al máximo antes obtenido, todo esto
durante un periodo de tiempo dado. En este caso este periodo de tiempo es el valor guardado
en los registros 32 y 33 (ver tabla 4.1) y los valores pico que se mostrarán son los del THD.
Debido a ser un valor solo demostrativo este valor no fue monitoreado para hallar sus
valores pico, en vez de eso fue generado aleatoriamente con rangos desde 0 hasta 20.99 %,
este será almacenado en los registros 42 y 43 y se formará de la siguiente manera:
73
registro[42] = rand()%21, registro[43] = rand()%100 (4.20)

THDmax/t = registro[42] + (registro[43]/100)
Además de crear los valores antes explicados la función medidor también realiza las siguientes
tareas:
 Verifica cada 6 minutos que el NodoM le envíe los 10 dígitos de su propio Número de
Serie, estos dígitos serán almacenados en las variables registro[83] al registro[93], si este
número de serie no es recibido o no coincide el medidor se apagará automáticamente.
(significa que el medidor se cambió físicamente)
 Guarda los datos acumulados en la memoria FLASH, cada minuto.
 Monitorea la bandera modbus_check para detectar si un nuevo mensaje del NodoM ha
sido recibido.
Tabla 4.7. Variables globales y locales usadas por f_medidor

-Para MODBUS
-Número esclavo del medidor
-Para contar minutos
-Variables acumulativas de Potencia (8 bits)
-Bandera para alertar de un msj. MODBUS
-Para guardar mediciones aleatorias
-Para potencia instantánea inventada

-Para guardar registros de tiempo
-Para leer, escribir o borrar memoria FLASH
Tabla 4.8. Diagrama de flujo de f_medidor
Voltaje (unidades y decenas) = de 10 a 30

Voltaje (decimales) = de 0 a 99
Corriente = de 0 a 30
Corriente (decimales) = de 0 a 99
frecuencia = de 59 a 60
frecuencia (decimales) = de 0 a 99
factor de potencia = de 65 a 99
factor de potencia (decimales) = de 0 a 99
distorsión armónica total = de 0 a 20
distorsión armónica total (decimales) = de 0 a 99
-se obtiene y guarda la hora dentro de time
-de time se obtienen los minutos
74
Tabla 4.8.b Diagrama de flujo de f_medidor
-Las siguientes variables se generan cada minuto:

rel_ang = 100*tan(arccos(fp/100)) = de 1 a 100
dwatt = potencia activa (decimas) = de 0 a 99
dVAr = potencia reactiva (decimas) = de 0 a 99
watt = potencia activa = de 0 a 4000
VAr = Potencia activa respecto rel. angular
Wh = a los watt acumulados se le suman los
instantáneos promediados durante 60 minutos
KWh = Wh/1000
dKWh = se obtienen décimas y centésimas de KWh
VArh = a los VAr acumulados se les suman los
instantáneos durante una hora
KVArh = VArh/1000
dKVArh = se obtienen décimas y centésimas de
KVArh
Se incrementa cont_mins (contador de minutos)
- Verifica cada 6 minutos que el NodoM le envíe los 10

dígitos de su propio Número de Serie:
-Se comenzará un contador j
-En este bucle se compararán uno a uno del registro[0]

al registro[9] (número de serie) con los registro[83] a
registro[93] (registros de verificación), en cada
coincidencia j será incrementada
-Si los 10 dígitos del número de serie coincidieron, el

registro[17] conservará su valor (ya sea 1 o 0)
-Si no coinciden se pondrá en 0 (medidor apagado)
-Después de haber checado se pondrán en cero

nuevamente los registros de verificación (del
registro[83] a registro[93])
-El contador de minutos también se pondrá en cero
-Se actualiza el número de esclavo (por si es que fue

modificado)
-Si registro[17]=0 se apaga medidor (en este caso

simulado el LED Rojo)
-Si registro[17]=1 uno se enciende medidor (en este caso
simulado el LED Rojo)
75
Tabla 4.8.c Diagrama de flujo de f_medidor

Se almacenan los datos ficticios
generados en los campos de registro
0 0 _ _ _ _._ _ V
_ _ 0 1 _ _._ _ V
_ _ _ _ x x ._ _ V
_ _ _ _ _ _ .x x V
0 0 _ _ _ _._ _ A
_ _ 0 0 _ _._ _ A
_ _ _ _ x x ._ _ A
_ _ _ _ _ _. x x A
x x._ _ Hz
_ _.x x Hz
x x._ _ %
_ _.x x %
x x._ _ %
_ _.x x %
x x _ _ _ _._ _ KWh
_ _ x x _ _._ _ KWh
_ _ _ _ x x._ _ KWh
_ _ _ _ _ _.x x KWh
x x _ _ _ _._ _ KVArh
_ _ x x _ _._ _ KVArh
_ _ _ _ x x._ _ KVArh
_ _ _ _ _ _.x x KVArh
x x._ _ THD/t
_ _.x x THD/t
Si se ha cambiado de minuto
-Se borrara el sector 0xF000 de la

memoria FLASH
-Para después almacenar todo el

contenido de la variable registro
-Se actualiza la variable para

monitorear el minuto anterior
Finalmente checa si se ha recibido

algún mensaje MODBUS,
-si es el caso ejecuta la función
f_MODBUS( )
76
4.1.1.5 f _MODBUS( )
Esta función es llamada al detectar un mensaje recibido por el puerto serie (ver eventos en la
sección 4.1.3.1) y sus tareas son:
 Desactivar el temporizador TI1.

 Ejecuta la función f_analizar_mensaje( ) para analizar el mensaje recibido y ejecutar la
acción correspondiente.
 Checará por medio de variables que el mensaje MODBUS sea correcto.
 Si el mensaje MODBUS fue correcto se formará el mensaje de respuesta y se enviará.
Tabla 4.9. Variables globales usadas por f_MODBUS

-Variable para alojar el número de esclavo del medidor
-Variables utilizadas como banderas para checar el
mensaje MODBUS recibido
-Contador de bytes usado en RS485_OnRx( )
Tabla 4.10. Diagrama de flujo de f_MODBUS
-Se desactiva el temporizador TI1
-Se ejecuta la función para analizar el mensaje recibido
Se checa que se cumplan los siguientes puntos:

-Que el número de esclavo del medidor coincida con el del
mensaje recibido
-Que el Número de esclavo esté entre el 2 y el 255
-Que el CRC del mensaje recibido sea correcto
-Que el número de datos recibidos en el mensaje sea el
adecuado según la instrucción
Si se cumplen las condiciones anteriores se ejecutan las

Funciones para crear y enviar el mensaje de réplica.
-Se resetea la bandera de mensaje MODBUS

-Se resetea el contador de bytes recibidos del puerto serie
77
4.1.1.6 f _analizar_mensaje( )
Esta función analiza los mensajes recibidos seccionándolos y revisando cada una de sus partes y
llenando las variables x_check en caso de que se cumplan o no los requisitos de un mensaje
MODBUS correcto. Las variables utilizadas por esta función son:
Tabla 4.11. Variables globales y locales usadas por f_analizar_mensaje
-Mensaje recibido del cual se extraen los demás datos
-Variables para el número esclavo, instrucción y error
-Mensaje ya sin num. esclavo, instrucción y CRC
-CRCR del mensaje_recibido y CRC calculado
-Contador de bytes usado en RS485_OnRx( )
-Usada para los bucles for
-Para indicar a cuantos bytes se les calculara el CRC
-Para apunta al arreglo al que se le calculará el CRC
Tabla 4.12. Diagrama de flujo f_analizar_mensaje
Del mensaje recibido:
-Se resetean las banderas
-Los primeros dos bytes serán: número de esclavo y

número de instrucción
-A mensaje_recibido se le quitan los dos primeros y dos

últimos bytes para formar datos_recibido
-De mensaje_recibido los dos últimos bytes se guardarán

en crc
-Se establece a cuantos bytes de mesaje_recibido se les

calculará CRC, y se apuntan con ap_crc
-Las variables anteriores serán los parámetros para
calcular el CRC
-Se verifica que el CRC del mensaje recibido (crc[1] y

crc[2]) coincida con el CRC calculado (crc_a y crc_b)
-No coincide CRC; se termina f_analizar_mensaje( )

-Si coincide CRC, se avisa con la bandera y
Se procede a checar si el número de esclavo en el
mensaje (num_disp) es el mismo que el del medidor
(numes_med) o es 0 (mensaje broadcast)
-Si se cumple se procede a checar la instrucción, sino
se termina la función
78
Tabla 4.12.b. Diagrama de flujo f_analizar_mensaje

-Se considera hasta ahora cero
errores, se activa la bandera
-Si la instrucción es la 0x03 y el

esclavo es entre el 2 y el 255, se
ejecuta f_lee_multi
-Si la instrucción es la 0x06 se
ejecuta f_escribe_uno
-La instrucción 0x10 ejecuta
f_escribe_multi
-Si no fue ninguna de las
instrucciones anteriores se finaliza
con el error 0x01 (instrucción
desconocida)
4.1.1.7 f _calcular_crc( )
Esta función hará el cálculo del CRC MODBUS a 16 bits (ver Apéndice A.3) de cualquier
mensaje al que se le dirija por medio de sus parámetros de entrada.
Tabla 4.13. Variables globales y locales usadas por f_calcular_crc
-Variables para alojar el CRC calculado
- Auxiliares para los bucles for
-Auxiliares para el cálculo del CRC
Tabla 4.14. Diagrama de flujo de f_calcular_crc
-El algoritmo se repetirá (long_crc) veces
crcsum=crcsum xor mensaje_recibido[i] and 0x00FF
-Por byte se ejecutará el cálculo de crcsum 8 veces
crcshift = (crcsum >> 1) and 0x00FF
-Se checa si ese primer bit es 1 o 0
-Si es 1: crcsum = crcshift XOR 0xA001

-Si es 0: crcsum = crcshift
-Finalmente crcsum se guarda en dos variables de 8

bits, siendo así el CRC calculado final
79
4.1.1.8 f _lee_multi( )
Todas las variables y datos generados u obtenidos por el medidor se almacenan en la variable
registro. Esta instrucción es la 0x03 (ver detalles en la sección 5.1.1) del protocolo MODBUS y
con ella se podrán leer dos o más registros del medidor.
Tabla 4.15. Variables globales y locales usadas por f_lee_multi

-Variable para acciones MODBUS
-Datos que se recibieron y datos que se enviarán
-Alerta si un mensaje tiene la cantidad correcta de bytes
-Si no es así se creará un error
-Contador de bytes del mensaje recibido
-Contador de bytes de los datos a enviar (mensaje total–4)
-Variables auxiliares
Tabla 4.16. Diagrama de flujo de f_lee_multi
-A partir de este registro se comenzará a leer

-Se obtiene cuantos bytes serán leídos
-Un mensaje de petición “ MODBUS 0x03” debe

tener solo 8 bytes de longitud, si esto no se cumple
-Si se cumple se pone en uno esta bandera
-Si los datos a leer están antes del registro[83] (del

83 al 100 están restringidos) se continuará con la
lectura, sino se creará el error 0x22
-Se forma el mensaje de respuesta comenzando

por el número de bytes a enviar
-Se forma el resto el resto del mensaje replica

excepto los últimos dos bytes correspondientes al
CRC
-d es el contador de bytes del mensaje réplica - 4
(num. esclavo, instrucción y 2 de CRC)
-Este error anuncia que el registro solicitado no

tiene permiso de lectura
-Esta variable será usada por f_formar_replica( )
80
4.1.2.9 f _escribe_uno( )
Esta instrucción es la 0x06 del protocolo MODBUS (ver detalles en la sección 5.1.2) y con ella se
podrá escribir en un solo registro del medidor a la vez. Las variables y algoritmo son:
Tabla 4.17. Variables globales y locales usadas por f_escribe_uno

Tabla 4.18. Diagrama de flujo de f_escribe_uno
-Se obtiene el registro en el que se desea escribir

-Un mensaje de petición “ MODBUS 0x06” debe
tener solo 8 bytes de longitud, si esto no se cumple
-Los únicos registros con permiso para escritura

individual con la instrucción 0x06 son el 16, 17,
32 y 33. Si se trata de escribir en otro se generará
el error 0x02
-Se puede escribir en los registros (16, 17, 32 o

33) dirigiéndose solo a los esclavos 2 al 255
-Se guardará el dato en el registro deseado
-Se forma el resto el resto del mensaje replica

sin los últimos dos bytes correspondientes al
CRC
-d es el contador de bytes del mensaje réplica -
4 (num. esclavo, instrucción y 2 de CRC)
-Dirigiéndose al esclavo 0 (broadcast) se puede
escribir en registro (17, 32 o 33)
-Error 0x22, registro que no permite escritura

-Si se trata de escribir en algún registro más allá
del 99 se generará el error 0x02 (registro no
disponible)
81
4.1.2.10 f _escribe_multi( )
Esta instrucción es la 0x10 (ver detalles en la sección 5.1.3) del protocolo MODBUS y con ella
se podrá escribir en varios registros del medidor a la vez. Las variables y algoritmo son:
Tabla 4.19. Variables globales y locales usadas por f_escribe_multi

Tabla 4.20. Diagrama de flujo de f_escribe_multi
Se obtiene el registro en el que se desea comenzar

a escribir y la cantidad de bytes a escribir
Un mensaje de petición “ MODBUS 0x10” debe

tener (9+n bytes a escribir) de longitud, si esto no
se cumple se termina la función
Los únicos registros con permiso para escritura
múltiple son el 32 y 33 así como los de verificación
(del 83 al 99).
-Si se cumple lo anterior se procede a escribir los

datos recibidos en los campos de registro
pertinentes
-Después se forma el mensaje de réplica
-d es el contador de bytes del mensaje réplica - 4

(num. esclavo, instrucción y 2 de CRC)
Error de registro que no permite escritura
82
4.1.2.11 f _formar_replica( )
Después de ejecutar las funciones f_lee_multi, f_escribe_uno o f_escribe_multi se habrá
generado la variable datos_replica si todo salió bien, pero si se generó algún error esta función lo
identificará y creará la variable datos_replica correspondiente (ver errores MODBUS en la sección
5.1.4) y posteriormente se creará mensaje_replica el cual será enviado de vuelta al NodoM. Las
variables aquí utilizadas son:
Tabla 4.21. Variables globales y locales usadas por f_formar_replica

-num. esclavo, instrucción y datos que se recibieron
-Mensaje y datos a enviar como réplica
-Contador de bytes de datos a enviar (mensaje total–4)
-Longitud de mensaje_replica, contador de bytes del
mensaje recibido y apuntador de mensaje_replica
Tabla 4.22. Diagrama de flujo de f_formar_replica
-Se comienza el mensaje_replica con el número de

esclavo y la instrucción
-Se checa si se generó el error 0x01, si es así se formará

el mensaje pertinente (instrucción no valida)
-Si la condición anterior no se cumple, entonces se

checa si se generó el error 0x02, si es así se formará el
mensaje pertinente (registro no valido)
-Si la condición anterior tampoco se cumple, entonces

se checa si se generó el error 0x22, si es así se formará
el mensaje pertinente (error de escritura)
-Se procede a formar el mensaje_ replica utilizando

la variable datos_replica previamente generada
-Longitud indicará el número final de bytes a enviar
83
Tabla 4.22.b. Diagrama de flujo de f_formar_replica
-Formado el mensaje_replica se calculará su CRC
-Los 2 bytes generados por el CRC se anexarán al final

de mensaje_replica y finalmente se apuntará con ap_tx
para poder enviarlo a la red RS485
4.1.2.12 f _enviar_replica( )
Después de crear mensaje_replica solo basta activar al chip RS485 y enviar por comunicación
serie la respuesta MODBUS al NodoM.
Tabla 4.23. Variables globales y locales usadas por f_enviar_replica

-Variable para apuntar a mensaje_replica y enviarlo vía serial
Tabla 4.24. Diagrama de flujo de f_enviar_replica
-Se pone en 1 (modo transmitir) el chip RS485
-Se envía mensaje_replica por comunicación serial a

la red RS485
-Se regresa a 0 (modo recibir) el chip RS485
4.1.2 Interrupciones programadas en el Medidor (Eventos)

En la sección de eventos del programa “medidor” (Ver código en Apéndice C.3) se escribieron las
siguientes funciones que serán llamadas por interrupciones del microcontrolador, básicamente
estas interrupciones son utilizadas para el control del puerto serial definido en “processor expert”
con el nombre de “RS485”.
84
4.1.3.1 RS485_OnRxChar
Cuando un mensaje de la red RS485 MODBUS comienza a ser recibido se llama a esta
interrupción, la cual estará siendo activada por cada nuevo byte entrante. Los datos irán siendo
guardados en la variable mensaje_recibido, adicionalmente se estará inicializando al temporizador
TI1 (el cual dura 1 milisegundo) y a la variable timmer = 5, esto con el fin de detectar el fin de
recepción de datos. En otras palabras si pasan 5ms desde el último byte recibido puede darse por
finalizada la recepción de datos en el puerto serie. Las variables a usar son las siguientes:
Tabla 4.25. Variables globales y locales usadas por RS485_OnRxChar

-Variable para contar milisegundos
-Arreglo donde se guardarán los bytes recibidos contados
por n
-Variable para recibir un byte del puerto serie
Tabla 4.26. Diagrama de flujo de RS485_OnRxChar
-Si un byte ha sido recibido sin errores será

guardado en ch
-para después ser guardado en mensaje_recibido
-Después de cada byte recibido se inicializa el

temporizador TI1
-timmer establece cuantas veces (milisegundos)
será reactivado TI1 antes de finalizar la recepción
-n se irá incrementando para asignar la posición
siguiente en mensaje_recibido a cada nuevo byte
4.1.3.2 TI1_OnInterrupt
Cada vez que esta interrupción sea llamada (debido a que transcurrió 1 milisegundo) se
decrementará la variable timmer, una vez que timmer=0 se pondrá a la bandera modbus_check=1
para avisar que un mensaje MODBUS ha sido recibido por el puerto serie del microcontrolador.
Tabla 4.27. Variables globales usadas por TI1_OnInterrupt

-Variable para
contar milisegundos
-Variable monitoreada por f_medidor para identificar cuando un
nuevo mensaje MODBUS ha sido recibido por completo
85
Tabla 4.28. Diagrama de flujo de TI1_OnInterrupt
-Si timmer llega a cero
-Se pondrá modbus_check=1 para avisar que se recibió un nuevo

mensaje MODBUS
-Si timmer aún no vale cero
-solo se decrementará uno
4.1.3.3 RS485_OnTxChar
Una vez que se comienza a transmitir por el puerto serie será llamada esta interrupción en la cual
se ha programado un bucle para autodispararse hasta que se termine de enviar el mensaje al que
apunte la variable ap_tx.
Tabla 4.29. Variables globales usadas por RS485_OnTxChar
-Variable paracontar los bytes enviados

-Apuntador a la variable que será transmitida por el puerto serie
Tabla 4.30. Diagrama de flujo de RS485_OnTxChar
-Por cada nuevo byte transmitido se incrementa ap_tx

-mientras que el contador de bytes longitud será
decrementado
-Mientras el contador de bytes a transmitir longitud sea

mayor a cero se enviará por el puerto serial el byte
apuntado por ap_tx
86
4.2 Programa NodoM
La programación se llevó a cabo con las mismas herramientas que en el caso del MedidorE. Las
tareas del NodoM programadas son:
 El NodoM tiene una lista (arreglo creado en memoria RAM del tipo byte llamada
lista_verificacion mostrado en la tabla 4.31) con los números de serie de cada MedidorE
que administra. Solo los medidores correctamente agregados en esta lista podrán estar
activos (conectando al usuario a la red) y ser intercomunicados con el CMD, el manejo de
esta lista y su adecuado respaldo en memoria FLASH son tarea del programa explicado en
esta sección.
 El enlace entre CMD y NodoM se realiza por medio de una red LoRa mientras que el
enlace entre NodoM y MedidorE se realiza por medio de una red RS485, ambas redes
realizan transmisión y recepción de datos por medio de una interfaz a puerto serial por lo
que el NodoM hará el control y monitoreo constante de los puertos serie que utiliza para
comunicarse analizando cada mensaje recibido tanto por el CMD como por los MedidorE.
 El NodoM tendrá tres roles en cuanto al protocolo MODBUS, a veces será el maestro, a
veces será un esclavo y otras veces será un intermediario entre el maestro y los esclavos;
esto dependiendo el tipo de tarea a ejecutar o el mensaje recibido del CMD.
o Maestro MODBUS: El programa del NodoM estará continuamente enviando un mensaje

de verificación para mantener funcionando a cada Medidor de su lista, en este caso el
NodoM actuará como maestro que controla a los Medidores esclavos.
o Esclavo MODBUS: El programa del NodoM tiene una serie de instrucciones especiales
(con formato MODBUS pero no son instrucciones propias del protocolo MODBUS)
para administrar a la lista_verificacion, dichas instrucciones serán enviadas por el CMD
y para el manejo de estas instrucciones específicas ahora el NodoM actuará como el
esclavo 1 MODBUS mientras que el CMD será el maestro.
o Intermediario: Cuando el CMD envía un mensaje MODBUS con destino a los esclavos
de entre el 2 al 254, es decir para algún MedidorE, el NodoM deberá convertirse en ese
momento en un simple intermediario pasando el mensaje del CMD (el cual será el
maestro MODBUS) a la red RS485 para que alguno de los MedidorE (que serán los
esclavos MODBUS) lo reciban, interpreten y hagan las acciones pertinentes.
Se puede ver a la variable lista_verificacion (tabla 4.31) como una tabla o matriz de 256 filas por
16 columnas. Cada fila corresponderá a cada número de esclavo por lo que se tendrán del esclavo
0 al 255, siendo el 0 un valor restringido, el 1 el esclavo del propio NodoM dejando disponibles
del 2 al 255 para los medidores. Cada columna representa un byte de los 16 posibles para un
87
número de serie de un medidor; para esta tesis el número de serie del MedidorE solo posee 10
dígitos, por lo que quedan libres y disponibles (para alguna tarea o valor adicional) 6 dígitos por
medidor.
Tabla 4.31. Variable lista_verificacion, donde se almacenan los números de serie de los medidores agregados en el
NodoM
Números de Serie Libres y disponibles
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Restringido 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
NodoM 1 xx xx xx xx xx xx xx xx xx xx 00 00 00 00 00 00
2 xx xx xx xx xx xx xx xx xx xx 00 00 00 00 00 00
Medidores
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
4.2.1 Funciones programadas en el NodoM

Al igual que el programa MedidorE, las siguientes funciones han sido programadas en una tarjeta
de desarrollo FRDM-K64F, y son las responsables de hacer funcionar este NodoM.
f_main( ) Es la función principal que se ejecutará la mayor parte del tiempo. Cuando el
microcontrolador es reiniciado ejecutará solo una vez a la función f_inicia_nodoM(). Esta
función presenta un bucle infinito que estará llamando continuamente a la función
f_checa_lista( ) y verificando la bandera CMDmsj_check para ver si no se ha recibido un
mensaje del CMD, en caso de que si mandará llamar a f_nvomsj_CMD.
f_inicia_nodoM( ) Cada vez que el NodoM se apague todos los datos que están en la memoria
RAM se perderán. Es imprescindible que los números de serie de los MedidorE sean
respaldados en la memoria FLASH para que se conserven aun después de desconectar al
NodoM. Cuando el NodoM sea reiniciado se ejecutará esta función con el fin de cargar los
valores previamente guardados en la memoria FLASH.
f_checa_lista( ) Es la función responsable de monitorear su lista_verificacion. Cada tres minutos

(tiempo contado con el reloj TmDt1) estará leyendo una a una sus 254 posiciones, y para
cada una tratará de conectarse al MedidorE correspondiente (mediante la función
f_checa_medidor) si es que existiera.
f_checa_medidor( ) Será llamada para checar cada una de las 254 posiciones de
lista_verificacion, primero revisará que dicha posición tenga agregado algún número de
serie, y si lo tiene entonces forma una parte del mensaje MODBUS necesario para poder
88
conectarse (mediante la función f_conecta_medidor) con el MedidorE correspondiente. Una

vez enviado el mensaje de petición esperará el mensaje de respuesta del MedidorE por unos
milisegundos, si dicha respuesta no llega enviará el mensaje dos veces más.
f_conecta_medidor( ) Esta función es llamada para comunicarse mediante una petición MODBUS
con algún MedidorE, formará el mensaje_aMODBUS y después se conectará a través de la
red RS485 para que alguno de los medidores lo reciba. Hecha la trasmisión esperará una
respuesta durante 100ms. También controla el estado del módulo RS485 (transmitir o recibir)
cuando es necesario.
f_calcular_crc( ) En esta función se ejecuta el algoritmo para el cálculo de CRC MODBUS a 16

bits. El resultado se guarda en dos bytes (crc_a y crc_b).
f_nvomsj_CMD( ) Esta función es llamada cuando se detectó un nuevo mensaje del CMD, dicho
mensaje se analiza con f_analizar_mensaje( ) si este es correcto generará la respuesta
correspondiente dependiendo el tipo de instrucción (si fue instrucción MODBUS para algún
medidor también checa que se halla recibido una respuesta por medio de
MODBUSmsj_check), los mensajes de respuesta hacia el CMD se crean y envían con
f_formar_replica.
f_analizar_mensaje( ) Esta función analizará los mensajes recibidos por alguno de los dos puerto
seriales (provenientes del CMD o de algún MedidorE) para calcular su CRC (llama a
f_calcular_crc() ) y compararlo, también verifica a quien se dirige el mensaje (llamando a
f_checar_numdisp() ). Adicionalmente verifica el número de instrucción a ejecutar mediante
f_checar_instruc().
f_checar_numdisp( ) Esta función verifica el número de esclavo para identificar si el mensaje

proveniente del CMD está dirigido al NodoM (esclavo 1), a todos los medidores de la red
RS485 (esclavo 0) o a algún MedidorE en específico, para este último caso primero buscará
que dicho medidor este agregado en la misma posición (dentro de lista_verificacion) que el
número de esclavo dice.
f_checar_instruc( ) Si el número de dispositivo al que se dirige el mensaje fue el 1 (es decir que
es para el NodoM) checa que la instrucción a ejecutar sea alguna de las siguientes: 0x00,
0x0A, 0x0B, 0x0C, 0x0D, 0x0E o 0x0F. Si el número de esclavo es 0 (mensaje broadcast
para todos los medidores) o es mayor que 1 (va para algún MedidrE en específico) llama a
las instrucciones MODBUS (f_instruc_MODBUS( )).
f_nodo_0x00( ) Instrucción dirigida al NodoM (esclavo 1). Esta función tiene el propósito de
reconfigurar el radio LoRa conectado en el puerto serial RADIO. El mensaje de
reconfiguración para el radio LoRa consta de 23 bytes y debe ser formado previamente (ver
ejemplo en la sección 4.3.3.1), los 23 bytes se anexan en la parte de datos del mensaje y al
reconocer esta instrucción son enviados nuevamente al radio LoRa como un mensaje de
89
respuesta (mensaje_replica), este reconocerá que es un mensaje para el y para cambiar su

configuración y no un mensaje para enviar de regreso al CMD.
f_nodo_0x0A( ) Instrucción dirigida al NodoM (esclavo 1). Esta instrucción dará una vista previa
de la lista_verificacion. Tras enviar esta instrucción como petición el NodoM enviará como
respuesta: el número de serie del NodoM (10 bytes), cantidad de medidores agregados en
este NodoM (1 byte) y la distribución de estos (32 bytes, ver ejemplo de uso en la sección
5.2.1.5). Generará como respuesta 43 bytes en datos_replica.
f_nodo_0x0B( ) Instrucción dirigida al NodoM (esclavo 1). Esta función mostrará los dígitos del
número de serie del medidor agregado en alguna de las 255 posiciones (filas) de
lista_verificacion.
f_nodo_0x0C( ) Instrucción dirigida al NodoM (esclavo 1). Por medio de esta instrucción se
podrá dar de alta a un nuevo medidor dentro del NodoM guardando su número de serie en
alguna de las 254 posiciones disponibles (de la 2 a la 255) de la lista_verificacion. Esta
función primero buscará si el MedidorE a agregar no está ya en la lista_verificacion, si no
es así entonces lo guardará tanto en la RAM como en el respaldo que se tiene en FLASH. En
ambos casos, que se agregue o no el medidor generará una respectiva respuesta.
f_nodo_0x0D( ) Instrucción dirigida al NodoM (esclavo 1). Esta función es contraria a la anterior,
eliminará del NodoM los datos de alguna de las posiciones de la lista_verificacion
(exceptuando la 0 y 1), hará la actualización en la memoria FLASH y creará una respuesta,
ya sea de error o de OK según sea el caso.
f_nodo_0x0E( ) Instrucción dirigida al NodoM (esclavo 1). Esta función busca algún MedidorE
dentro del NodoM en base de su número de serie (no en base a su número de esclavo) para
lo cual checará las 256 posiciones de la lista_verificacion. Como respuesta enviará el
número de posición (esclavo) donde está el MedidorE deseado, o una respuesta de error en
caso de que no se encuentre.
f_nodo_0x0F( ) Instrucción dirigida al NodoM (esclavo 1). Función que borra todo el contenido
de lista_verificacion a excepción de las posiciones 0 y 1. Actualizará el respaldo de que se
tienen en la memoria FLASH y después ejecutará función f_inicia_nodoM para actualizar
con los nuevos valores.
f_instruc_MODBUS( ) Instrucción (puede ser la 0x03, 0x06 o 0x10) dirigida a la red RS485, ya
sea al esclavo 0 o a algún MedidorE. En este caso el programa toma el mensaje recibido por
el puerto serial RADIO (mensaje proveniente del CMD) y lo retransmitirá por el puerto
serial RS485 usando la función f_conecta_medidor( ). Hecho lo anterior checa que también
se reciba un mensaje de respuesta (mensaje_deMODBUS) por el mismo medio para copiarlo
y enviarlo al CMD. Con esta función el NodoM se portará como simple intermediario entre
CMD y MedidorE.
90
f_formar_replica( ) Esta función se encarga de formar el mensaje_replica el cual es el que será

enviado como respuesta MODBUS al NodoM. Tomando previamente los datos
(datos_replica) generados por las funciones anteriores o creando la respuesta
correspondiente en los casos de errores. Agrega primero el número de esclavo, después la
instrucción, seguido de los valores guardados en datos_replica, se calcula y se anexa el CRC.
RS485_OnRxChar( ) Evento llamado cada que se recibe un byte por el puerto serial RS485, irá
formando el mensaje_recibido, adicionalmente se encarga de activar el timmer TI1 y a la
variable timmer=5 con el fin detectar cuando un mensaje ha sido recibido por completo y
notificará con la bandera recibio_datos.
RADIO_OnRxChar( ) Evento similar al anterior pero para monitorear los mensajes recibidos
por el puerto serial RADIO.
TI1_OnInterrupt( ) Evento del timmer TI1 llamado cada 1ms, tratará de contar 5ms después de
cada byte recibido por RS485_OnRxChar( ) o por RADIO_OnRxChar( ) e indicará cuando
se ha terminado de recibir un mensaje (del NodoM o del CMD). Adicionalmente usará a
timmer2 para contar el tiempo que esperará (100ms) para recibir un mensaje una vez que se
usó f_conecta_medidor( ).
RS485_OnTxChar( ) Evento usado para transmitir byte por byte un mensaje a través del puerto
serial RS485, una vez que se ha comenzado a enviar dicho mensaje este evento será llamado
continuamente hasta haber enviado la cantidad de: longitud_MODBUS bytes.
RADIO_OnTxChar( ) Evento usado para transmitir byte por byte un mensaje a través del puerto
serial RADIO, una vez que se ha comenzado a enviar dicho mensaje este evento será llamado
continuamente hasta haber enviado la cantidad de: longitud bytes.
A continuación se explican cada una de las funciones del programa NodoM comenzando con una
breve descripción, siguiendo con una lista donde se muestran las variables utilizadas por dicha
función (las de recuadro verde son variables globales y las de recuadro amarillo son variables
locales) y finalmente su correspondiente diagrama de flujo con una explicación más detallada. Las
configuaciones de los componentes de Processor Expert se muestran en el Apéndice D.1, y para
comparar con el programa escrito en “CodeWarrior” se recomienda ver código en el Apéndice D.2.
4.2.1.1 f _main( )
Esta es la función principal encargada de inicializar el NodoM cargando los valores guardados
anteriormente en la memoria FLASH. Checará si se ha recibido algún nuevo mensaje del puerto
RADIO (proveniente del CMD) y ejecutar infinitamente el programa NodoM.
91
Tabla 4.32. Diagrama de flujo de main

Esta es la función principal.
Al encender el medidor se ejecutará la función

f_inicia_nodom( ) la cual cargará la lista de verificación de
los medidores dados de alta y respaldados en la FLASH.
Se crea un bucle infinito que continuamente estará ejecutando

la función f_checa_nodom( )
Se estará verificando permanentemente si un nuevo mensaje

proveniente del CMD
4.2.1.2 f _inicia_nodoM( )
Esta función leerá de la memoria FLASH todos los datos almacenados previamente y los copiará
en la variable lista_verificacion la cual es un arreglo que está en la memoria RAM y será en donde
se guardan los números de serie de los medidores registrados, esta lista_verificacion será leída y
escrito por las instrucciones especiales CMD-NodoM. Las variables y algoritmo se muestran a
continuación:
Tabla 4.33. Variables globales y locales usadas por f_inicia_nodoM
-Lista de los medidores que el NodoM mantendrá activos
-Variables auxiliares y para cargar los datos de la FLASH
-Dirección en la que se hace el respaldo en la memoria FLASH
Tabla 4.34. Diagrama de flujo de f_inicia_nodoM

La variable lista_verificacion puede verse
como una tabla o matriz de 256 filas x 16
columnas
-Se inicia un bucle para leer las filas

respaldadas en la memoria FLASH a partir
de la direccion 0xF000
-Un segundo bucle se encarga de leer los
bytes de cada fila
-Los datos leídos se almacenan en Dato en
paquetes de 16 bytes y posteriormente se
almacena en la RAM en la variable global
lista_verificacion
92
4.2.1.3 f _checa_lista( )
Esta función cada 3 minutos ejecutará las demás funciones necesarias para enviar el mensaje de
verificación a cada uno de los medidores que están dados de alta en la matriz lista_verificacion las
variables y algoritmo utilizados por esta función son:
Tabla 4.35. Variables globales y locales usadas por f_checa_lista

-Usadas para guardar los tiempos de verificación
-Variable usada para contar los medidores que van
siendo verificados
-Variable especial para guardar los datos de tiempo
generados por TmDt1
Tabla 4.36. Diagrama de flujo de f_checa_lista
-Se toma el tiempo de TmDt1
-Del tiempo adquirido se toman los minutos
-Si se cumple la condición se detectó un nuevo

minuto
-Si es así se refresca la variable de minuto

anterior y se incrementa el contador de minutos
-Si el contador de minutos llega a 3
-El contador de medidores comenzará con el

esclavo 2 y se resetea el contador de minutos
-Mientras no se llegue de nuevo al esclavo 0

-Se verifica el medidor esclavo k
-Se pasará el siguiente número de esclavo
-No existe lugar para esclavo 256 por lo tanto si
- k llega a este número se pone de nuevo a 0
93
4.2.1.4 f _checa_medidor( )
Esta función formará el mensaje de verificación para mantener activo al MedidorE k. El mensaje
de verificación consiste en escribirle al MedidorE k los 10 dígitos de su número de serie en los
espacios 83 a 96 de su registro MODBUS. El MedidorE estará leyendo continuamente estos
registros y verificando que el número escrito ahí sea el mismo que su número de serie, y de no ser
así el medidor procederá a desactivarse (desconectar al usuario de la red eléctrica). Para escribir
este mensaje de verificación se hará uso de la instrucción MODBUS 0x10 (escritura de múltiples
registros) y los datos que se escribirán serán leídos de la lista_verificacion que posee el NodoM.
En resumen el NodoM deberá tener previamente agregado en su lista_verificacion al MedidorE
k para mantenerlo activo, debiendo coincidir tanto los 10 dígitos del número de serie como la
posición del esclavo k (recordar que k comprende desde el 2 al 255). Estará checando a todos los
medidores de su lista cada 3 minutos así como los medidores estarán checando el mensaje de
verificación en un lapso de tiempo similar o ligeramente mayor. Las variables utilizadas y el
algoritmo se muestran a continuación:
Tabla 4.37. Variables globales y locales usadas por f_checa_medidor

-Lista con Medidores a mantener activos
-Bandera de que el MedidorE recibió el mensaje
-Mensaje MODBUS final para enviar a MedidorE
-Mensaje base para formar la petición 0x10 que se
enviará al MedidorE a verificar
Tabla 4.38. Diagrama de flujo de f_checa_medidor
-Primero se checa que haya un MedidorE con

número de esclavo k registrado en la
lista_verificación. Para hacer esto se checará que
los 10 dígitos de la posición k de la lista sean
diferentes de 0. Si no se cumple se termina la
función.
-Si se cumple entonces se procede a
-formar el mensaje MODBUS de verificación que

será enviado al medidor
-en dicho mensaje se agregan los 10 dígitos

registrados en la posición k de lista_verificacion
94
Tabla 4.38.b Diagrama de flujo de f_checa_medidor
-el mensaje de verificación siempre será de 19

bytes
-Se envía el mensaje de verificación al MedidorE
k
-En caso de que el mensaje de verificación no
tuviera respuesta correcta se enviará 2 veces más
4.2.1.5 f _conecta_medidor( )
Esta función tiene el propósito de enviar por el puerto serial RS485 cualquier mensaje formado
hacia el o los MedidorE deseados. Para dicha tarea desactiva primero la comunicación el CMD
(realizada con el puerto llamado RADIO) y activa el módulo RS485 así como al temporizador TI1
el cual también actuará sobre la variable timmer2 utilizada para crear un tiempo de espera de
100ms para el mensaje de respuesta del MedidorE. El proceso y variables utilizadas se muestran
a continuación:
Tabla 4.39. Variables globales y locales usadas por f_conecta_medidor
-Mensaje para enviar al MedidorE
-Mensaje respondido por el MedidorE
-Secciones del mensaje del CMD
-Bandera de mensaje replica de MedidorE
-Temporizador para espera de respuesta de MedidorE
y contadores de bytes recibidos
-Apuntador para mensaje a MedidorE
Tabla 4.40. Diagrama de flujo de f_conecta_medidor
-m es el contador de bytes recibidos del puerto serial

RS485 con el MedidorE, se comenzará en 0
-al igual que la variable de aviso de mensaje recibido
-Se calcula CRC del mensaje a enviar
-El resultado del CRC calculado se anexa en los

últimos 2 bytes de mensaje_aMODBUS
-Se desactiva el puerto serial RADIO
-y se activa el puerto serial de RS485
-También se pone el chip MAX485 en transmisión
95
Tabla 4.40.b Diagrama de flujo de f_conecta_medidor

-Se apunta al comienzo del mensaje a enviar
-Y se envía por el puerto RS485 al MedidorE

-Después de enviar, se pone al MAX485 en modo
recepción
-se ajustará una variable para contar 100ms
-y se habilitará el temporizador TI1
- timmer2 se decrementará cada ms hasta llegar a 0,

de esta manera se formará un retardo de 100 ms para
esperar un mensaje de respuesta del MedidorE
-Recibido el mensaje o pasado el retardo se
desactivara el temporizador TI1
-Se desactiva de nuevo el puerto RS485
-Se vuelve a activar el puerto serial RADIO para
seguir a la espera de comunicaciones con el CMD
4.2.1.6 f _calcular_crc( )
El programa NodoM al igual que MedidorE utiliza el mismo algoritmo para calcular CRC MODBUS a 16 bits por lo que si se
desea ver esta función se sugiere revisar la sección 4.1.1.7.
4.2.1.7 f _nvomsj_CMD( )
Durante la función f_inicio( ) se estará monitoreando continuamente la variable CMD_msjcheck
la cual valdrá “0” generalmente. Cuando un mensaje proveniente del CMD comienza a recibirse a
través del puerto serial RADIO entrarán las funciones de interrupción o eventos para poder recibir
y cuantificar el mensaje entrante; seguido a esto la variable CMD_msjcheck valdrá “1” y entonces
la función f_nvomsj_CMD( ) será llamada con el fin de poder interpretar este mensaje recibido,
comenzando por separar el número de esclavo, instrucción MODBUS, datos y CRC. Para ver
detalladamente el proceso de detección de datos recibidos ver los eventos de NodoM en la sección
4.2.2. Si se identificó alguna instrucción MODBUS será ejecutada y finalmente se generará el
mensaje de respuesta o error para devolver al CMD.
Tabla 4.41. Variables globales y locales usadas por f_nvomsj_CMD

-Para guardar la instrucción
-Para avisar si se son correctos CRC y esclavo
-Para avisar de nuevo mensaje CMD o MedidorE
-Contador de bytes recibidos del CMD
-Usada para avisar si se mandará replica o no
96
Tabla 4.42. Diagrama de flujo de f_nvomsj_CMD
-Se desactiva el temporizador TI1 ya que se cumplió la

detección de un nuevo mensaje en el puerto RADIO
-Se analizará el mensaje recibido por el puerto RADIO
-Si después de analizar el mensaje recibido se cumple

que el número de esclavo (numdisp_check) y el CRC
(crc_check) son correctos:
-se procede a identificar si es una de las 3 instrucciones

MODBUS, y si no fue instrucción MODBUS entonces
fue instrucción CMD-NodoM y se autorizará generar
respuesta para el CMD
-si fue instrucción MODBUS se checa si se recibió
un mensaje de respuesta por parte del MedidorE
-si así fue se autoriza generar replica para el CMD
-Si se autoriza replicar se comenzará
formando el mensaje de replica
para después enviarla al CMD
-Se resetea la variable que alerta

y el contador de bytes recibidos del puerto RS485
4.2.1.8 f _analizar_mensaje( )
La tarea de esta función es revisar el mensaje recibido proveniente del CMD, lo divide en número
de esclavo (num_disp), instrucción (instruc), datos (datos_recibido) y crc (crc), después manda
calcular el crc para compararlo con el del mensaje recibido, después analiza el tipo de dispositivo
al que se dirige el mensaje y finalmente analiza y ejecuta la instrucción. A continuación se muestran
las variables y diagramas de flujo.
Tabla 4.43. Variables globales y locales usadas por f_analizar_mensaje
-Guarda el mensaje recibido del CMD
-El mensaje se divide en estas 4 secciones
-Banderas para corroborar esclavo, instrucción y crc
-Contador de bytes recibidos
-Auxiliar
97
Tabla 4.44. Diagrama de flujo de f_analizar_mensaje
Reseteo de banderas
-Se obtiene de mensaje_recibido el
número de esclavo e instrucción
-Se obtienen todos los datos
-Se obtiene el CRC del mensaje

recibido
-Se calcula el CRC del mensaje

recibido
-Se compara el CRC recalculado con el

de mensaje recibido, si coinciden se
registrará en crc_check y continuará el
análisis
-Se checa el tipo de dispositivo
-si es válido el dispositivo se procede

a checar y ejecutar la instrucción
4.2.1.9 f _checar_numdisp( )
Esta función solo identificará primero si el dispositivo al que se dirige el mensaje es un MedidorE
registrado en la lista_verificacion, si es el dispositivo 1 (NodoM), el dispositivo 0 (mensaje
broadcast) o ninguno de los anteriores. Según sea el caso lo registrará en la variable
numdisp_check. Las variables y algoritmo son los siguientes:
Tabla 4.45. Variables globales y locales usadas por f_checar_numdisp

-Variables utilizadas
-Auxiliar
98
Tabla 4.46. Diagrama de flujo de f_checar_numdisp
-En lista_verificacion se buscará la

posición del MedidorE con
esclavo=num_disp , y se checará que los
10 dígitos de su número de serie sean
diferentes de cero, así se verifica que exista
un medidor agregado en dicha posición
-Se checa que num_disp cumpla el punto

anterior o que sea 0 o 1
-Si se cumple alguna de las anteriores se

notificará mediante numdisp_check=1
4.2.1.10 f_checar_instruc( )
Después de identificar a que esclavo se dirige el mensaje seguirá identificar la instrucción que se
desea ejecutar, dependiendo el dispositivo al que se dirige el mensaje puede que la instrucción
funcione o no. Mientras las instrucciones MODBUS (0x03, 0x06 y 0x10) solo serán válidas para
los esclavos del 2 al 255 (MedidorEs), y en ocasiones para el 0 o broadcast; las instrucciones
CMD-NodoM (0x00, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E y 0x0F) servirán solamente para el esclavo
1 (NodoM). Finalmente contará que el número de bytes sean los adecuados según el tipo de
instrucción utilizada. Esta función hace dicho análisis y relación dispositivo-instrucción para
continuar con la ejecución de la instrucción o para generar un error MODBUS.
Tabla 4.47. Variables globales y locales usadas por f_checar_instruc

-Variablesutilizadas
99
Tabla 4.48. Diagrama de flujo de f_checar_instruc
-Si el mensaje va para el esclavo 1 (NodoM):
-Si la instrucción es la 0x00 el mensaje debe

ser de 27 bytes para poder ejecutar
f_nodo_0x00
-Si la instrucción es la 0x0A el mensaje debe
f_nodo_0x0A
-Si la instrucción es la 0x0B el mensaje debe

f_nodo_0x0B
-Si la instrucción es la 0x0C el mensaje debe

f_nodo_0x0C
-Si la instrucción es la 0x0D el mensaje debe

f_nodo_0x0D
-Si la instrucción es la 0x0E el mensaje debe

f_nodo_0x0E
-Si la instrucción es la 0x0F el mensaje debe

ser de 6 bytes para poder ejecutar f_nodo_0x0F
-Si no cumple con el tamaño genera error 0x03

-Si no fue ninguna de las instrucciones
anteriores genera el error 0x01
-Si el mensaje va para el esclavo 0 (broadcast) o

para cualquiera del 2 al 255 (MedidorE): se
ejecuta el set de instrucciones MODBUS
4.2.1.11 f_nodo_0x00( )
Esta instrucción se usará en caso de que se desee reprogramar el radio LoRa conectado al NodoM.
La función f_analizar_mensaje separó previamente del mensaje proveniente del CMD los bytes
100
pertenecientes a los datos (datos_recibido), estos mismos bytes serán guardados sin cambio alguno
en la variable mensaje_replica para volver a ser enviados por el puerto RADIO al rx del radio
LoRa el cual debido a la naturaleza del mensaje lo identificará como mensaje para el mismo y en
vez de transmitirlo como un mensaje cualquiera lo tomará para realiza los cambios pertinentes a su
configuración. En el Apéndice F.3.1 se explica dicho proceso en base a los parámetros a configurar
y como generar dicho mensaje de configuración. A continuación se enlistan las variables usadas
así como el diagrama de flujo.
Tabla 4.49. Variables globales y locales usadas por f_nodo_0x00
-Mensaje a enviar por el puerto RADIO
-Contador de bytes de la sección datos (total de bytes - 4)
del mensaje a ser enviado
-Contador de bytes recibidos del CMD y sus datos
-Auxiliar
Tabla 4.50. Diagrama de flujo de f_nodo_0x00
-Por medio de este bucle se formará la variable

mensaje_replica copiando solo los datos
(datos_recibido) del mensaje de configuración
recibido previamente
-d es un contador de datos del mensaje replica a

transmitir, recordar que la sección datos involucra al
mensaje total menos 4 bytes (num. esclavo,
instrucción, crc_a y crc_b)
4.2.1.12 f_nodo_0x0A( )
Esta instrucción nos dará una vista previa del NodoM en específico de la lista_verificacion (ver
detalles en la tabla 4.31). Tras enviar esta instrucción como petición el NodoM enviará como
respuesta los siguientes datos: número de serie del NodoM (primeros 10 bytes), cantidad de
medidores agregados en este NodoM (1 byte) y la distribución de los medidores agregados (32
bytes, donde cada byte mostrará 8 posiciones de lista_verificacion, se deberá visualizar en código
binario para ver así que posiciones están ocupadas (1 = medidor agregado, 0 = vacío) siendo el
primer bit del primer byte el esclavo 0 y el ultimo bit del byte 32 el esclavo 255) , ver ejemplo de
uso en la sección 5.25. Las variables y el algoritmo se muestran a continuación:
Tabla 4.51. Variables globales y locales usadas por f_nodo_0x0A
-Lista de los números de serie de medidores agregados
-Datos de mensaje a enviar como respuesta
-Contador de bytes de datos_replica
-Cantidad de medidores y distribución en binario
-Auxiliares para los contar posiciones, valores y bucles
101
Tabla 4.52. Diagrama de flujo de f_nodo_0x0A
-g contará las filas que ya se revisaron (desde 0 a

255)
-j cuenta para los bits de cada byte (del 0 al 8)
-Se checa solo el primer byte de cada fila de

lista_verificacion, si vale 0 no hay medidor ahí
registrado y se avanza de posición
- Y así 8 veces.
- Si se encuentre un medidor dependiendo el

valor que tenga j se le asignará un valor a k lo
cual puede interpretarse como k=2^j , también
se incrementara el contador de medidores
llamado cantidad_meds
- h indicará el byte en el que se va registrando
(cada byte guardará datos de 8 filas)
- Cuando j llegue a 8 se guardará el valor
obtenido por k dentro de posis_nodom[h]
reseteará a j y k con el fin de empezar a revisar
las siguientes 8 filas y almacenar los resultados
encontrados en un nuevo byte de posis_nodom
-Revisadas las 255 filas de lista_verificacion se

comenzara a formar datos_replica comenzando
con los 10 dígitos del número de serie del NodoM
guardo en la fila 1
-Después se guardará el número de medidores que
se encontraron
-Finalmente se agregan los 32 bytes de
posis_nodom donde se muestra por código
binario las posiciones ocupadas con medidor o
vacías
-Este mensaje de respuesta tendrá un total de 43
bytes en la sección de datos
102
4.2.1.13 f_nodo_0x0B( )
Esta función mostrará los dígitos del número de serie del medidor agregado en alguna de las 255
posiciones (filas) de lista_verificacion (ver ejemplo en sección 5.23). Las variables y diagrama se
flujo son los siguientes:
Tabla 4.53. Variables globales y locales usadas por f_nodo_0x0B
-Lista de los números de serie de medidores agregados
-Datos de mensaje a enviar como respuesta
-Auxiliares para los bucles
Tabla 4.54. Diagrama de flujo de f_nodo_0x0B
-Esta posición (fila) de lista_verificacion será

revisada
-Se cargan los 10 valores de dicha fila (pueden
ser un número de serie o solo ceros si no existe
medidor)
-mensaje_replica tendrá 10 bytes en su parte

de datos
4.2.1.14 f_nodo_0x0C( )
Con esta instrucción se podrá dar de alta a un nuevo medidor dentro del NodoM, esto implica
registrar su número de serie en alguna de las 254 filas disponibles (de la 2 a la 255) de la
lista_verificacion con el propósito de que el NodoM pueda estar reactivando a dicho MedidorE
cada pocos minutos. De esta manera se asegura que un MedidorE solo funcionará conectado en el
NodoM que lo tenga registrado en la posición (equivalente al número de esclavo) asignada,
recibiendo el mensaje de verificación adecuado para poder seguir funcionando. Se puede ver un
ejemplo de aplicación en la sección 5.2.2.
Tabla 4.55. Variables globales y locales usadas por f_nodo_0x0C

-Guardará los medidores registrados
-sección de datos del mensaje recibido de CMD
-Sección de datos para formar respuesta a CMD
-Contador de bytes para datos_replica
-Guarda el número de esclavo o posición
-Arreglos para los números de serie a guardar
-Dirección en memoria FLASH
103
Tabla 4.56. Diagrama de flujo de f_nodo_0x0C
-Se copiara en ns los 10 dígitos

del número de serie que vienen
en el mensaje del CMD
-Se checa que los dígitos del

nuevo Num. de Serie ns no
estén ya agregados en alguna
de las 255 filas de
lista_verificacion, por cada
dígito que coincida agregado
se incrementará, si llega a 10
quiere decir que el medidor ya
había sido agregado
-Si la posición a agregar el

nuevo medidor no es la 0 ni la
1, y el medidor no ha sido
agregado:
Se podrá entonces agregar al
nuevo medidor en la posición
deseada
-Se borra el sector de FLASH
-Se procederá a actualizar la

lista_verificacion con el nuevo
medidor ya agregado y se
copiará en vector_grabar
-Se podrá hacer la copia en el

sector de memoria FLASH
previamente borrado
-Si la fila seleccionada estuvo

disponible y se guardó el nuevo
num. del MedidorE se creará
un 0x00, 0x00 como respuesta
-Si no, la respuesta será 0xFF,

0Xff
-Solo serán 2 bytes en la

sección datos de la respuesta
104
4.2.1.15 f_nodo_0x0D( )
Contraria a la anterior, con esta función se eliminará de la lista_verificacion del NodoM algún
MedidorE previamente agregado, para más información ver ejemplo de aplicación en la sección
5.26. El proceso y variables se muestran a continuación:
Tabla 4.57. Variables globales y locales usadas por f_nodo_0x0D

-Guardará los datos de los medidores
-Datos del mensaje recibido
-Datos del mensaje replica
-Contador de bytes de datos
-Posición de lista_verificacion a borrar
-Auxiliares para manipular números de serie
-Dirección de memoria FLASH para respaldos
Tabla 4.58. Diagrama de flujo de f_nodo_0x0D
-Primero checa que las posiciones a

borrar no sean la 0 ni la 1
-Si se cumple lo anterior se procede

a poner en ceros la posición
(esclavo) de lista_verificacion
-Se borra el sector de FLASH
-Se comienza a grabar una a una

cada posición de lista_verificacion
actualizada usando de intermedio a
vector_grabar, se irán grabando
bloques de 16 bytes partiendo de la
dirección (0xF0000) y generando
los saltos sumando (j+0x10)
-Si el proceso de respaldo en la

FLASH se realizó se generará la
respuesta 0x00, 0x00
-Si no, se generará la respuesta

0xFF, 0xFF
-La sección de datos de esta
función es de 2 bytes
105
4.2.1.16 f_nodo_0x0E( )
Si se necesita buscar algún MedidorE dentro de la lista_verificacion del NodoM pero no se

conoce su posición (número de esclavo) como para usar la instrucción f_nodo_0x0B se podrá
utilizar esta instrucción para encontrar al medidor en base de su número de serie, se puede ver
ejemplo de aplicación en la sección 5.24. Se muestra a continuación las variables y el proceso:
Tabla 4.59. Variables globales y locales usadas por f_nodo_0x0E

-Arreglo donde se guardan los números serie
-Variables de sección de datos de mensajes
-Contador de bytes para datos_replica
-Auxiliares
-variable para alojar el número de esclavo
Tabla 4.60. Diagrama de flujo de f_nodo_0x0E
-Del mensaje recibido por el CMD se obtienen

los 10 dígitos del número de Serie a buscar
-Comenzará a explorarse desde la posición 1 de

lista_verificacion
-Variable usada como bandera, cuando vale 10 ya

se encontró al medidor que se busca
-En este bucle se analizan uno a uno los 10 dígitos

-Comparando los del mensaje recibido con los de
la posición i
-Por cada dígito que coincida agregado se
incrementará
-Si vale 10 se genera como respuesta: 0x00,0Xyy

siendo YY el número de posición (esclavo donde
está ubicado el MedidorE)
-Si no vale 10 no se encontró el medidor y la

respuesta será 0xFF,0xFF
-La longitud de datos_replica es de 2 bytes
106
4.2.1.17 f_nodo_0x0F( )
Finalmente si se desea borrar todo el contenido de matriz_nodom se debe usar esta instrucción la
cual borrará las posiciones desde la 2 a la 255, respetará únicamente la 0 dejándola vacía y la 1
(número serie del NodoM). Esta función primero modificará el respaldo de lista_verificacion que
se tienen en la memoria FLASH y después ejecutará función f_inicia_nodoM para cargar la
lista_verificacion con los nuevos valores. Se puede ver el ejemplo de aplicación en la sección
5.2.1.
Tabla 4.61. Variables globales y locales usadas por f_nodo_0x0F
- Guarda los datos de medidores
- Parte de datos del mensaje de respuesta
- Contador de bytes de la sección datos
- auxiliar
- Número Serie del NodoM
- Variable con ceros para resetear
- Dirección de la FLASH donde se hacen
los respaldos
Tabla 4.62. Diagrama de flujo de f_nodo_0x0F
-Se borra el sector de la FLASH
-Se respalda primero el número

de serie del NodoM
-A partir de la posición 2 hasta la

255 se comenzará a grabar el
vector_reset el cual tiene solo
ceros
-Se reinicia la lista_verificacion

llamando a f_inicia_nodoM
-Después de hacer el reseteo se

formará de respuesta: 0x00,
0x00
-Solo hay 2 bytes en la sección

datos de mensaje_replica
107
4.2.1.18 f_instruc_MODBUS( )
Cuando en el mensaje del CMD para el NodoM está implícita una instrucción MODBUS (0x03,
0x06 y 0x10) la función f_analizar_mensaje la identificará y ejecutará entonces a esta instrucción,
cuyo propósito principal será retransmitir el mensaje del CMD recibido por el puerto serial RADIO
hacia el MedidorE por medio del puerto serial llamado RS485, en este caso podrá decirse que el
CMD será el maestro, el MedidorE el esclavo MODBUS y el NodoM un intermediario.
Tabla 4.63. Variables globales y locales usadas por f_instruc_MODBUS

-Para guardar los mensajes MODBUS de
petición y réplica hacia el MedidorE
-Sección de datos de mensaje_replica
-Mensaje proveniente del CMD
-Bandera de mensaje recibido de MedidorE
y longitud del mensaje a enviar a MedidorE
-Auxiliar
Tabla 4.64. Diagrama de flujo de f_instruc_MODBUS
-Se copia en mensaje_aMODBUS el

mensaje_recibido del CMD
-Tendrá el mismo número de bytes
-Formado el mensaje se envía al MedidorE

correspondiente
-Si se recibió respuesta del MedidorE se habrá

guardado en mensaje_deMODBUS y con esta se
creará la sección de datos para la respuesta al
CMD
-Tendrá la misma longitud en bytes y se le restan

los 2 primeros y los 2 últimos
4.2.1.19 f_formar_replica( )
Esta función se encargar de terminar de construir el mensaje replica que será devuelto al CMD a
través del puerto RADIO (en las funciones previas referentes a las instrucciones se formó la parte
de datos) comenzando el mensaje_replica con el número de esclavo que responde (pudiendo ser
108
algún MedidorE o el NodoM), seguido por la instrucción (0x03, 0x06, 0x10, 0x0A, 0x0B, etc.),
después se agrega la sección correspondiente a los datos que ya fue construida previamente, y se
termina el mensaje poniendo al final los 2 bytes correspondientes al CRC del mensaje_replica.
Finalmente se apuntará al mensaje para que pueda ser transmitido por el puerto serial RADIO.
Tabla 4.65. Variables globales y locales usadas por f_formar_replica

-Secciones del mensaje recibido del CMD
-Mensaje de respuesta, y su sección de datos
-Contador de bytes totales de mensaje_replica
-Apuntador del mensaje a transmitir al CMD
-Auxiliar
Tabla 4.66. Diagrama de flujo de f_formar_replica
-Solo la instrucción 0x00 genera respuesta

especial
-Se obtienen del mensaje_recibido el número de
esclavo a quien se dirige y la instrucción
-Se agregan los datos ya formados antes al

mensaje_replica
-Longitud final en bytes del mensaje_replica
-Se calcula el CRC del mensaje_replica
-El CRC calculado se añade al mensaje_replica
-La instrucción 0x00 devolverá por el puerto

RADIO únicamente los bytes que venían en la
sección de datos de mensaje_recibido para
reconfigurar al radio LoRa
-Por lo que su longitud será de 4 bytes menos
-Formado ya mensaje_replica será apuntado para
-poderse enviar por el puerto serial RADIO
109
4.2.2 Interrupciones del NodoM (Eventos)

En la sección de eventos del programa “NodoM” (Ver código en Apéndice D.3) se escribieron las
siguientes funciones que serán llamadas por interrupciones del microcontrolador, básicamente
estas interrupciones son utilizadas para el control de los dos puertos seriales definidos en
“Processor Expert” como: RADIO y RS485.
4.2.2.1 RS485_OnRxChar
Cuando un mensaje MODBUS de la red RS485 comienza a ser recibido se llama a esta
interrupción, la cual estará siendo activada por cada nuevo byte entrante. Los datos irán siendo
guardados en la variable ch, enseguida se estará incrementando a m como un contador de bytes
usado para asignar a cada nuevo byte recibido dentro de mensaje_recibido. Por cada nuevo byte
se estará inicializando al temporizador TI1 (de 1 milisegundo) y a la variable timmer = 5, esto con
el fin de detectar el fin de recepción de datos. En otras palabras si pasan 5ms desde el último byte
recibido puede darse por finalizada la recepción de datos en el puerto serie. Las variables a usar
son las siguientes:
Tabla 4.67. Variables globales y locales usadas por RS485_OnRxChar
-Bandera para confirmar la recepción de bytes
-Arreglo donde se guardarán los bytes recibidos
-contados por m
-Variable para recibir un byte del puerto serie RS485
Tabla 4.68. Diagrama de flujo de RS485_OnRxChar
-Si un byte ha sido recibido sin errores será guardado en

ch
-Esta bandera alerta de bytes recibidos por el puerto serial

temporizador TI1
-timmer establece cuantas veces (milisegundos) será
reactivado TI1 antes de finalizar la recepción
-m se irá incrementando para asignar la posición siguiente
en mensaje_recibido a cada nuevo byte
110
4.2.2.2 RADIO_OnRxChar
De manera muy similar a la anterior solo que esta función estará trabajando para el puerto serial
llamado RADIO el cual recibirá los datos del CMD. La única diferencia con RS485_OnRxChar
es que el contador de bytes utilizado esta vez será n.
Tabla 4.69. Variables globales y locales usadas por RADIO_OnRxChar

-Bandera para confirmar la recepción de bytes
-Arreglo donde se guardarán los bytes recibidos
-contados por n
-Variable para recibir un byte del puerto serie RS485
Tabla 4.70. Diagrama de flujo de RADIO_OnRxChar
-Si un byte ha sido recibido sin errores será guardado

en ch
-Esta bandera alerta de bytes recibidos por el puerto

serial
temporizador TI1
-timmer establece cuantas veces (milisegundos) será
reactivado TI1 antes de finalizar la recepción
-n se irá incrementando para asignar la posición
siguiente en mensaje_recibido a cada nuevo byte
4.2.2.3 TI1_OnInterrupt
Esta interrupción es llamada por el evento generado por el temporizador TI1 (el cual contará 1
milisegundo). Será utilizada por RS485_OnRxChar y por RADIO_OnRxChar como temporizador
para detectar el fin de recepción de datos seriales y por f_conecta_medidor para crear un retardo
de 100ms con el fin de esperar el mensaje MODBUS de respuesta de un MedidorE. En cualquiera
de los casos anteriores cada que este evento sea generado se decrementarán las variables timmer
y timmer2 (inicializadas previamente con algún valor) hasta que lleguen a 0. Cuando la variable
timmer llegue a 0 se pondrán a las banderas CMDmsj_check y MODBUSmsj_check a 1 para
avisar que un mensaje serial ha sido recibido por el microcontrolador ya sea por su puerto RADIO
o RS485. Las variables y algoritmo usados son las siguientes:
111
Tabla 4.71. Variables globales usadas por TI1_OnInterrupt

-Bandera para alertar de que se recibió un byte por algún puerto serial
-Variables para contar milisegundos
-Banderas para alertar de
Tabla 4.72. Diagrama de flujo de TI1_OnInterrupt
-Si timmer llega a cero y también la bandera recibio_datos fue

puesta a 1 por RS485_OnRxChar o por RADIO_OnRxChar
entonces se alertara de que un mensaje serial ha sido recibido por
completo
-Se pondrán tanto a CMDmsj_check
como a MODBUSmsj_check en 1
para avisar que se recibió un nuevo mensaje por puerto serial
-Y se reseteara con 0 a la bandera recibio_datos
-Tanto timmer como timmer2 serán decrementadas hasta llegar a 0.

Una vez que valen cero ya no se les hará nada por medio de este
evento hasta que de nuevo tengan un valor mayor (sean
inicializadas)
4.2.2.4 RS485_OnTxChar
Una vez que se comienza a transmitir por el puerto serial llamado RS485 será llamada esta
interrupción en la cual se ha programado un bucle para autodispararse hasta que se termine de
enviar el mensaje al que apunte la variable ap_txM.
Tabla 4.73. Variables globales usadas por RS485_OnTxChar

-Para contar los bytes a ser enviados por el puerto serial RS485
-Apuntador a la variable que será transmitida por el puerto serial.
112
Tabla 4.74. Diagrama de flujo de RS485_OnTxChar
-Por cada nuevo byte transmitido se incrementará el

apuntador
-mientras que el contador de bytes longitud_MODBUS
será decrementado
-Mientras el contador longitud_MODBUS sea mayor a

cero se enviará por el puerto serial el byte apuntado por
ap_txM
4.2.2.5 RADIO_OnTxChar
Una vez que se comienza a transmitir por el puerto serial llamado RADIO será llamada esta
interrupción en la cual se ha programado un bucle para autodispararse hasta que se terminen de
enviar los longitud bytes del mensaje al que apunte la variable ap_tx.
Tabla 4.75. Variables globales usadas por RADIO_OnTxChar

-Para contar los bytes a ser enviados por el puerto serial RS485
-Apuntador a la variable que será transmitida por el puerto serial.
Tabla 4.76. Diagrama de flujo RADIO_OnTxChar
-Por cada nuevo byte transmitido se incrementará el

apuntador
-mientras que el contador de bytes longitud será
decrementado
-Mientras el contador longitud sea mayor a cero se

enviará por el puerto serial el byte apuntado por
ap_tx
113
4.3 Programa datalogger
Una de las tareas más sobresalientes tanto del CMD como de una AMI en general es la capacidad
de crear registros de las mediciones realizadas, guardando todos esos datos obtenidos en archivos
de almacenamiento y bases de datos a los que el Sistema Administrador deberá tener acceso de
manera rápida, remota, y permanente. Llamado datalogger.py, es el programa encargado de
cumplir dicha tarea, este es ejecutado permanentemente por el CMD. La programación se realizó
en la paquetería “Python” versión 2.7, el lenguaje de programación utilizado fue python y se hizo
uso de la herramienta “idle.py” tanto en Windows como en Linux. Las tareas del programa
datalogger.py pueden enlistarse de la siguiente manera:
 Este programa deberá ejecutarse permanentemente por el CMD.

 Debe leer constantemente el archivo (enviado o modificado por el administrador) llamado
lista_medidores.txt, este archivo tendrá un listado de todos los MedidorE´s a monitorear,
así como su número de serie, NodoM al que están conectados y el número de esclavo que
tienen programado.
 El archivo lista_medidores.txt, también lleva escrito el tiempo de “loggeo”, es decir cada
cuantos minutos se estarán tomando las mediciones de todos los medidores pertenecientes
a la AMI (ver figura 4.36), se guardará a dicho archivo dentro del CMD, en la carpeta del
servidor FTP específicamente.
 Este programa formará los mensajes MODBUS de petición necesarios para tomar lecturas
de cada MedidorE, es decir formará los mensajes con sus respectivos números de radio
LoRa (NodoM), número de esclavo MODBUS y CRC calculado, pidiendo leer los valores
de: número de serie, estado (conectado o desconectado), voltaje, corriente, factor de
potencia, frecuencia, THD, potencia activa acumulativa, potencia reactiva acumulativa y
THD máximo registrado desde la última medición.
 Usará el puerto serial (de la Raspberry Pi) para transmitir y recibir datos hacia la red LoRa
y así comunicarse con cada uno de los NodoM, los cuales a su vez se comunican con
muchos MedidorE.
 Esperará por una respuesta adecuada del pertinente MedidrE durante unos segundos, de
no ser así, volverá a enviar el mensaje de petición, este proceso lo hará máximo10 veces.
 Obtenidos los datos de cada MedidorE los mostrará imprimiendo en pantalla a través de la
terminal de Linux “LXTerminal”, así como también mostrará el número de veces que se
transmitió el mensaje para que llegará a su destino y la hora en la que se obtuvo la medición.
 Cada mes se creará un nuevo archivo de registro de mediciones para cada MedidorE. El
nombre de dicho archivo tendrá el siguiente formato:
“num. serie de MedidorE”_”mes”_”año”.txt
 Se guardará a un archivo dentro del CMD, en la carpeta del servidor FTP específicamente,
solo los datos de potencia activa acumulativa, potencia reactiva acumulativa y THD
114
máximo registrado desde la última medición, así como la fecha y hora en la que se tomó la
medición (ver figura 4.1).
El archivo lista_medidores.txt es un archivo de texto que será creado directamente por el

administrador, aunque la idea es que en un futuro este archivo pueda crearse de manera automática
desde el sitio web del Sitema Administrador (ver trabajos futuros sección 6.3). Los datos que
lleva se describen a continuación:
 En la primera línea se especifica el tiempo de adquisición de mediciones, es decir el tiempo

en minutos que transcurrirá entre en una toma de datos de todos los medidores de la AMI
y la siguiente. Cada que se cumpla este tiempo el CMD se conectará uno a uno con cada
MedidorE para tomar sus datos y registrarlos en el archivo correspondiente. El proceso se
repetirá hasta haber completado la toma de datos de todos los MedidorE´s includios en
lista_medidores.txt.
 De las las líneas 2 en adelante se agregan los MedidorE´s que serán monitoreados, en cada
línea se comenzará con el número de serie del medidor (en este trabajo de tesis se han
supuesto números de serie de 10 dígitos alfanuméricos). Separando por una coma sigue el
número de radio LoRa del NodoM en el que se encuentra agregado el MedidorE, este
número es de 4 dígitos y esta en hexadecimal por lo que podría expresarse desde el 0002
hasta el FFFF (el 0000 y 0001 están restringisdos). Finalmente también separado por una
coma sigue el número de esclavo que lleva asignado el MedidorE dentro del NodoM, este
consta de dos dígitos y también es expresado en hexadecimal pudiendo ser desde el 02 hasta
el FF (el 00 y 01 están restringidos). Como se puede ver cada línea asignada a un MedidorE
consta de solo 18 caracteres con comas incluidas, es muy importante respetar dicho formato
ya que el programa datalogger.py solo será capaz de interpretarlo de esa manera.
Tiempo en minutos
entre cada medición
Un MedidorE
en cada línea
Figura 4.1. Ejemplo del archivo lista_medidores.txt.
115
El archivo de registro de mediciones es aquel donde se guardaran los principales datos obtenidos
de cada MedidorE, así como la fecha y hora en que dicha medición fue tomada. Este será único
para cada MedidorE y solo guardará los registros de un mes, una vez que sea iniciado un nuevo
mes se creará otro archivo. El nombre de cada archivo estará compuesto de:
Número de serie de MedidorE + _ + mes corriente + _ + año corriente + .txt
Se podrá interpretar que cada línea del archivo de mediciones corresponde a una nueva medición
tomada. Los datos que lleva en cada línea de su interior se explican a continuación, ver también
figura 4.2:
 Fecha de medición con formato: día/mes/año

 Sigue un espacio (tabulador) y entonces la hora de medición con formato: hora:minuto
 Espacio (tabulador) seguido de la potencia activa: KWh con 2 cifras decimales
 Espacio (tabulador) seguido de la potencia reactiva: KVArh con 2 cifras decimales
 Espacio (tabulador) seguido de la distorsión armónica total máxima detectada desde la
última medición del THDMAX/t
Una medición
en cada línea
Fecha Hora KWh KVArh THDMAX / t
Figura 4.2. Ejemplo de un archivo de datalogger del medidor “m001XYZ000”

y con fecha de marzo del 2016: m001XYZ000_3_2016.txt.
116
4.3.1 Descripción de las funciones de datalogger.py

Las siguientes funciones han sido programadas en python 2.7 dentro de datalogger.py y ejecutadas
en el CMD (Raspberry Pi 2), son las responsables de comunicarse con cada medidor dentro de la
AMI para adquirir sus datos de mediciones y registrarlos en un archivo, el cual estará accesible por
medio del servidor FTP.
Programa principal: Este no es una función, sino más bien la primera parte a ser ejecutada y que
a su vez llamará a las demás funciones, específicamente a la función datalogger( )
dentro de un bucle infinito. El programa principal también carga las librerías de python
que se necesitaran como la de puerto serial, la de tiempo y la de manejo de estructuras.
También inicializa las primeras variables globales.
datalogger( ) Esta función se ejecutará permanentemente. Contará los minutos t_logeo entre una
toma de datos y otras, pasado ese tiempo llamará a la función ver_lista_meds( ) para
obtener la lista actualizada de los MedidorE que serán monitoreados nuevamente. Por
cada medidor se formará un mensaje MODBUS de petición con formar_msjs( ), se
abrirá o creará un archivo (si no existiera) para guardar los datos y se conectará al
MedidorE correspondiente con leer_medidor( ), finalmente guardará los datos
obtenidos mediante logear( ).
ver_lista_meds( ) Esta función se encargará de leer el archivo lista_medidores.txt para obtener

primero el próximo t_logeo por si este fue modificado y posteriormente creará una lista
completa de todos los MedidorE que serán nuevamente monitoreados, incluyendo sus
números de serie, NodoM en el que se encuentran y número de esclavo que tienen
asignado en dicho NodoM.
formar_msjs( ) Esta función formará los mensajes MODBUS de cada MedidorE ya que cada uno
tendrá diferentes números de NodoM, número de esclavo y CRC, para calcular este
último mandará llamar a la función CRCMODBUS( ). Finalmente guardará a dicho
mensaje como una estructura s_leer ya que solo así puede enviarse por medio del
puerto serial.
CRCMODBUS( ) Este es el algoritmo para calcular el CRC versión MODBUS de 16 bits para un
mensaje (conjunto de bytes), es exactamente el mismo que se programó en el NodoM
y en los MedidorE´s solo que en lenguaje python.
leer_medidor( ) Esta función realizará la conexión con el NodoM correspondiente para que a su
vez este se comunique con el MedidorE deseado, realizará el control del puerto serial
abriéndolo, limpiando datos para después transmitir a s_leer, posteriormente quedará
esperando (5 segundos) para recibir el mensaje de respuesta (que será guardado en
msj_replica) de 49 bytes proveniente del MedidorE-NodoM, si transcurrido este
tiempo no se recibieron los 49 bytes volverá a enviar el mensaje s_leer, esto se hará un
total de 10 veces. Si el mensaje de respuesta no se recibió mostrará en pantalla el error,
pero si se recibió mostrará en pantalla todos los datos obtenidos del MedidorE.
117
logear( ) Esta última función es la encargada de abrir el archivo (por ejemplo

m001XYZ000_3_2016.txt) donde se guardarán los datos de cada MedidorE por cada
lectura de datos se guardará una línea cadena la cual lleva la fecha, hora y
posteriormente los KWh, KVArh y THDmax /t. Finalmente mostrará en pantalla la hora
en la que se realizó el registro.
A continuación se explican cada una de las funciones comenzando con una breve descripción,
siguiendo con una tabla donde se muestran las variables utilizadas por dicha función (las de
recuadro verde son variables globales y las de recuadro amarillo son variables locales) y finalmente
su correspondiente diagrama de flujo con una explicación más detallada. Para comparar con el
programa escrito en “Python” se recomienda ver las líneas de código en el Apéndice E.2.
4.3.1.1 Programa principal

Programa principal, cuyas tareas son:
 Cargar las librerías utilizadas en todo el programa datalogger.py.
 Inicializar al MedidorE con los valores guardados anteriormente en la memoria FLASH.
 Ejecutar continuamente el programa principal de mediciones.
Tabla 4.77. Librerías (color rosa) y variables globales utilizadas por el programa principal
Librería de puerto serial.
Librería de hora.
Librerías para manejo de fecha y hora.
Librería para el manejo de estructura de bytes

Configuración del puerto serial
Tiempo de “loggeo” o toma de mediciones

Número de veces que se reenviará el msje. de petición
Variable donde se guardará el mensaje de respuesta
devuelto por el MedidorE
Tabla 4.78. Diagrama de flujo el programa principal
Además de cargar las librerías e inicializar las primeras

variables globales, el programa principal solo estará
mandando a llamar permanentemente a la función
datalogger( )
118
4.3.1.2 datalogger( )
Puede considerarse como la función más importante del programa ya que es la encargada de llamar
a las demás funciones para conectarse a cada MedidorE y registrar sus datos:
Tabla 4.79. Variables globales y locales utilizadas por la función datalogger

Variable para guardar el tiempo de “loggeo”
Usadas para contar minutos y
guardar tiempos
Usadas para guardar los datos de los MedidorE´s a loggear
Auxiliar, y bandera para indicar si se recibió respuesta
Para nombrar al archivo donde se guardarán los datos leídos
Tabla 4.80. Diagrama de flujo de la función datalogger
Se obtienen los datos de fecha y hora del

momento y se almacenan en variables
Se establece la siguiente hora en la que se

tomarán mediciones
Se checará la hora en el sistema hasta que se
llegue a la hora de la siguiente toma de
mediciones
Se actualizará la lista de MedidorE’s y el

tiempo de “loggeo” t_logeo
Se tomarán las mediciones de cada uno de los

MedidorE´s agregados en lista
Para cada MedidorE el num. de serie, num. de
NodoM y esclavo serán diferentes
Se crea el mensaje MODBUS para leer

múltiples datos del MedidorE
Se crea el nombre del archivo donde se
guardarán los datos
Se conectará y tomara datos del MedidorE
Se guardarán los datos en el archivo
119
4.3.1.3 ver_lista_meds( )
Función encargada de revisar el archivo con los medidores a loggear y guardar sus datos.
Tabla 4.81. Variables globales y locales utilizadas por la función ver_lista_meds
Tiempo entre una toma de mediciones y otra
Variable para referir al archivo leído y fila con datos de un MedidorE
Auxiliares para contar líneas y para ciclos for
Tabal donde se guardan los datos de los medidores a leer
Tabla 4.82. Diagrama de flujo de la función ver_lista_meds
Se abre el archivo lista_medidores.txt
Se lee la primer línea del archivo y con ese

valor se actualiza t_logeo
Se resetea el contador de líneas n
Se cuentan cuantas líneas tiene el archivo, la

última línea será la que ya no tiene ningún dato
(“ ”) aunque también será contada.
Se cierra el archivo
Se crea una lista con las mismas filas que las

líneas contadas por n menos la última línea
En cada fila serán agregados 3 índices mas
Se vuelve a abrir el archivo
De nuevo se revisa línea por línea
Pero esta vez se irán tomando carácter por

carácter que a su vez serán convertidos en
valor numérico y se guardarán en los espacios
correspondientes de la lista
Se cierra el archivo
Devuelve la variable lista a la función que
mando llamar a ver_lista_meds( )
120
4.3.1.4 formar_msjs( )
Función que creará el mensaje de petición de lectura múltiple MODBUS necesario para pedir a un
MedidorE los datos de los 49 registros donde se almacenan las mediciones eléctricas obtenidas, el
mensaje para cada medidor será única ya que estarán en diferentes NodoM, tienen números de
esclavo asignado diferentes y por lo tanto el CRC será diferente.
Tabla 4.83. Variables globales y locales utilizadas por la función formar_msjs

El mensaje MODBUS que será enviado por puerto serial
NodoM y num. de esclavo del MedidorE a leer
Variables adicionales para formar el mensaje
Tabla 4.84. Diagrama de flujo de la función formar_msjs
Variables para formar el mensaje de lectura que será

enviado a los MedidorE
El num. del radio LoRa o NodoM se divide en 2

bytes
Los 6 bytes del mensaje base de lectura MODBUS
Se calcula el crc del mensaje anterior base
Se unirán los bytes de radio, base y crc para formar

msj_leer
msj_leer se convertirá en una estructura de bytes

s_leer apta para enviar por comunicación serial
4.3.1.5 CRCMODBUS( )
Función que calcula el CRC MODBUS a 16 bytes de un mensaje (conjunto de bytes).
Tabla 4.85. Variables locales utilizadas por la función CRCMODBUS

El mensaje al que se le calculará el CRC
Auxiliares para el cálculo del CRC
Variables donde se guardarán los dos bytes del CRC calculado
121
Tabla 4.86. Diagrama de flujo de la función CRCMODBUS
El algoritmo se repetirá según el num. de bytes

del mensaje a calcular
crcsum=crcsum xor mensaje_recibido[i]
and 0x00FF
Por cada byte se ejecutará el cálculo de crcsum
8 veces
crcshift = (crcsum >> 1) and 0x00FF
Se checa si ese primer bit es 1 o 0
Si es 1: crcsum = crcshift XOR 0xA001

Si es 0: crcsum = crcshift
Finalmente crcsum se guarda en dos bytes

Y se devuelve en la variable crc
4.3.1.6 leer_medidor( )
Función que realiza la transmisión del mensaje s_leer por medio del puerto serial al módulo LoRa
para que llegué así al NodoM y MedidorE correspondientes. Enviado el mensaje esperará recibir
la respuesta, sino reenviará el mensaje hasta 9 veces más. Si se recibe o no la respuesta adecuada
se mostrará mediante la pantalla de la “LXTerminal”. Finalmente usará la variable leído_ok para
notificar si fue recibido o no el mensaje de respuesta.
Tabla 4.87. Variables locales utilizadas por la función leer_medidor( )

Num. de veces que se intentará enviar el mensaje
Variable que guardará el mensaje de respuesta del MedidorE
Variables auxiliares para checar la transmisión y recepción
Para guardar un tiempo de espera
Para guardar cada byte recibido por el puerto serial
Variable usada para indicar si se recibió bien el msj_replica
122
Tabla 4.88. Diagrama de flujo de la función leer_medidor
Funciones auxiliares iniciadas con cero
Se conecta el puerto serial
Mientras no se reciban 49 bytes y tampoco se

halla enviado el mensaje 10 veces será
ejecutado este bucle
Nuevamente se resetean estas variables
Se limpia el buffer Tx del puerto serial
Se transmite por vía serial el mensaje s_leer
Se espera por 500ms
Se limpia el buffer Rx del puerto serial
Se crea un tiempo de espera de 5 segundos
Mientras el tiempo de espera tf no termine y

no se hayan recibido los 49 bytes de
respuesta se ejecutará este bucle
Esperando se haya recibido un byte por el
puerto serial, sino volverá a checar la
condición anterior
Si se recibe byte se guarda en data
y byte a byte se forma msj_replica

El contador de bytes se incrementa
Recibidos 49 bytes o terminó tf se contará un
intento por enviar s_leer
Se cierra conexión con puerto serial
Si no se recibieron 49 bytes no se recibió la

respuesta esperada, lo cual se indicará con
leído_ok=0
123
Tabla 4.88.b. Diagrama de flujo de la función leer_medidor
Y se imprimirá en pantalla sobre los

intentos fallidos
Pero si se recibieron los 49 bytes se

interpreta como respuesta correcta y se
imprimirá también en pantalla junto
con los siguientes datos:
Los 10 dígitos del número de serie del

MedidorE leído
El número de esclavo dentro del

NodoM
Si el MedidorE estaba conectado o

desconectado
El valor del voltaje instantáneo leído
El valor de la corriente instantánea

leida
El valor de la frecuencia instantánea

leida
El valor del factor de potencia
instantáneo leído
El valor de la THD instantánea leida
El tiempo de adquisición de datos del

MedidorE
El valor de la potencia activa
acumulada leida
El valor de la potencia reactiva
acumulada leida
El valor de la THDmax registrada desde

la última lectura de datos
124
Tabla 4.88.c. Diagrama de flujo de la función leer_medidor

Finalmente se indica con esta
variable si se recibió la respuesta
correcta del MedidorE o no
4.3.1.7 logear( )
Función que guarda los datos leídos del MedidorE en su archivo correspondiente, agregando la
fecha y hora de la lectura realizada.
Tabla 4.89. Variables locales utilizadas por la función logear

El mensaje recibido del MedidorE
Nombre del archivo donde se guardará la medición y bandera
Variables que guardarán la fecha y hora de la medición
Variables que guardarán los valores a registrar en el archivo
Caracteres finales a guardar en el archivo, y auxiliar para hacer
referencia al archivo en el que se registran los datos
Tabla 4.90. Diagrama de flujo de la función logear
Se toman hora y fecha actuales y se

guardan en las respectivas variables
Si no se recibió el mensaje de
respuesta del MedidorE se
guardarán en los datos de las
variables “___”
Pero si se recibió la respuesta

adecuada se formarán los textos
con los respectivos valores leídos
Cadena de caracteres final a

guardarse en el archivo
Se abrirá el archivo donde
Se escribirá la cadena
Cierra el archivo
Se imprime en pantalla la hora en
que los datos han sido registrados
125
126
Capítulo 5: Pruebas y resultados

obtenidos
Después de haber sido expuestas todas las etapas de este trabajo de tesis, procedimientos, diseños
y herramientas utilizadas, resta explicar cómo es que se probaron y que resultados arrojaron al
final. En este capítulo se detallará sobre el funcionamiento de los dispositivos en las diferentes
etapas de este trabajo.
Este capítulo se divide en base a las pruebas y resultados obtenidos de los puntos siguientes:
 MedidorE
 NodoM
 Red LoRa
 Servidor FTP
 Almacenamiento de mediciones (datalogger)
 Sistema completo funcionando
127
El sistema NodoM-MedidorE desarrollado en este trabajo utiliza el protocolo MODBUS. Aunque

el protocolo estándar de comunicaciones MODBUS consta de casi 20 instrucciones (Apéndice A.3)
el sistema del medidor propuesto solo trabajará con tres (Apéndice A.3.1). Con estas tres funciones
se podrá tener acceso a las variables que el MedidorE disponga en el vector registro y rescribir en
las que tenga permitido.
 0x03: leer múltiples registros
 0x06: escribir un registro
 0x10: escribir múltiples registros
Para comunicarse y configurar al NodoM se crearon siete instrucciones especiales llamadas

instrucciones CMD-NodoM, estas utilizan la estructura de mensajes MODBUS (Apéndice A.3.2).
 0x00: reprogramar radio LoRa
 0x0A: explorar lista_verificacion
 0x0B: verificar medidor por número de esclavo
 0x0C: dar de alta medidor
 0x0D: dar de baja medidor
 0x0E: verificar medidor por número de serie
 0x0F: resetear lista_verificacion
Para realizar estas primeras pruebas se usó una PC como dispositivo maestro. Posteriormente se
usará ya el NodoM como maestro quien a su vez será coordinado remotamente por el CMD
(Concentrador de Medidores Digitales). El software de apoyo utilizado como terminal serial para
enviar datos es el sscom32e.exe (Figura 5.1) el cual se utilizó por su facilidad al enviar cadenas de
datos en hexadecimal aunque prácticamente puede usarse cualquier terminal que cumpla con esta
cualidad. Finalmente los mensajes enviados al MedidorE de pruebas se escribieron de forma
manual (todos son valores hexadecimales) directamente en la terminal mientras que su CRC
correspondiente fue calculado con el apoyo de una calculadora CRC online [41].
Mensaje de
respuesta del
medidor
Hace referencia al radio Mensaje de

0x0002, No tiene que ver petición al
con MODBUS medidor
Figura 5.1. Terminal SSCOM32E utilizada mostrando tanto el mensaje de petición enviado al medidor,
como el mensaje de respuesta generado por el medidor
128
5.1 Pruebas al MedidorE
Como ya se aclaró, este dispositivo MedidorE propuesto solo realiza mediciones ficticias, por lo
que las pruebas necesarias no se enfocan en comparación con mediciones reales, más bien las
pruebas realizadas deben enfocarse al sistema de comunicaciones implementado, es decir al buen
funcionamiento de la red RS485 y al protocolo de comunicaciones MODBUS por medio de los
cuales se debe tener un fácil y rápido acceso a los datos obtenidos por el medidor y que a su vez
permitirán que interactué fácilmente con el dispositivo siguiente en la red AMI propuesta, es decir
el NodoM. Expresado lo anterior se comenzará entonces demostrando el funcionamiento del
protocolo MODBUS programado para los MedidorE. Para ver los detalles de los datos leídos en
las siguientes pruebas consultar tabla A.1 de la sección A.3.1.
Nota: Todos los valores de los mensajes mostrados (escritos con letras de colores) en los
ejemplos siguientes son valores hexadecimales pero por practicidad de las explicaciones se
omitió el prefijo “0x”.
5.1.1 Prueba de la instrucción 0x03: leyendo múltiples registros

Para ejemplificar esta prueba se leerán por medio de la instrucción 0x03 los 10 dígitos del número
de serie del MedidorE. El proceso de lectura mediante la instrucción 0x03 consiste en formar la
palabra de petición en hexadecimal, como se ve en la tabla 5.1.
Tabla 5.1. Ejemplo de petición con la instrucción 0x03
0002 FF 03 00 00 0005 17 90
1 2 3 4 5 6
Este mensaje está compuesta por los siguientes datos:
1. Radio LoRa al que se dirige el comando (no forma parte del protocolo): 0x0002
2. El número de esclavo (número del MedidorE): 0xFF
3. Instrucción MODBUS de lectura múltiple: 0x03
4. El registro (expresado en 2 bytes) en el cual se iniciará la lectura: 0x0000
5. Número de palabras (expresado en 2 bytes) de 16 bytes a leer: 0x0005
6. Para finalizar, el CRC de los 4 datos anteriores (6 bytes): 0x1790
Tras enviar la petición si todo fue correcto el medidor de prueba deberá enviar el siguiente mensaje
de respuesta:
Tabla 5.2. Respuesta al mensaje de la tabla 5.1
FF 03 0A 6D 30 30 31 58 59 5A 30 30 30 8D80
129
Indicando primero el número de esclavo y la instrucción a la que responde: 0x FF 03,

posteriormente el número de bytes recibidos (10) 0x0A y después el número de serie: 0x6D 30 30
31 58 59 5A 30 30 30 equivalente (hexadecimal a ASCII) a “m001XYZ000”. Finalmente el CRC
calculado de los 12 bytes de la respuesta 0x8D80.
Se repitió esta prueba para leer todos los datos de la tabla A.1 obteniéndose resultados
satisfactorios, por lo que la programación de la instrucción 0x03 fue correcta.
5.1.2 Prueba de la instrucción 0x06: escribiendo un solo registro

En esta prueba se pretende activar y desactivar al MedidorE mediante la escritura de un solo
registro (el registro 17), para fines prácticos se ha programado al LED rojo de la FRDM-K64F
como monitor (registro [17]=0 = LED apagado = medidor desconectado o registro[17]=1 = LED
encendido = medidor conectado). El proceso de escritura de un solo dato mediante la instrucción
0x06 será el siguiente:
Tabla 5.3. Mensaje de petición con la instrucción 0x06 para activar al MedidorE 255
0002 FF 06 0011 0001 D10D
1 2 3 4 5 6
3. Instrucción MODBUS de escritura de un solo byte: 0x06
4. Registro (expresado en 2 bytes) en el cual se desea escribir. 17 en hexadecimal: 0x0011
5. El dato a escribir (expresado en 2 bytes) para activar al MedidorE: 0x0001
6. Para finalizar, el CRC de los 4 datos anteriores (6 bytes): 0xD10D
Tras enviar la petición si todo ha salido bien, el MedidorE deberá encender su LED rojo (Figura
5.2) simulando que ha sido activado además de enviar de regreso exactamente el mismo mensaje
como respuesta:
Figura 5.2. Tarjeta FRDM-KF64 simulando un medidor de pruebas siendo activado.
130
Tabla 5.4. Respuesta al mensaje de la tabla 5.3
0002 FF 06 0011 0001 D10D
Para probar que de igual manera se puede desactivar al medidor debe escribirse ahora un 0 en el
registro 17 (0x11), el mensaje de petición y el de respuesta son los siguientes:
Tabla 5.5. Mensaje para desactivar al MedidorE Tabla 5.6. Respuesta del MedidorE en caso OK
0002 FF 06 0011 0000 11CC FF 06 0011 0000 11CC
Adicionalmente deberá asignársele al MedidorE un nuevo número de esclavo ya que todos por
defecto vendrán configurados como esclavo 255. Para llevar a cabo esta tarea también se usará la
instrucción 0x06 escribiendo en el registro 16 (0x10) expresado en dos bytes es decir 0x0010. El
dato a escribir en esta caso será el número de esclavo que se deseé asignar como por ejemplo el 2,
el cual expresado en 2 bytes quedaría como 0x0002.
Tabla 5.7. Cambiar MedidorE de esclavo 255 a esclavo 2 Tabla 5.8. Respuesta en caso OK
0002 FF 06 0010 00 02 101C FF 06 0010 00 02 101C
El resultado de estas pruebas fue el deseado por lo que la programación de la instrucción 0x06 en
el MedidorE fue correcta.
5.1.3 Prueba de Instrucción 0x10: escribiendo en múltiples registros

Esta instrucción puede utilizarse en el MedidorE para ajustar el tiempo de adquisición de
mediciones por ejemplo, para esto se usarán el registro 32 que será para asignar horas y el registro
33 para minutos. En el siguiente ejemplo se configurará un tiempo de adquisición de mediciones
de 1 hora 30 minutos y el mensaje será el siguiente:
Tabla 5.9. Mensaje de petición con la instrucción 0x10 para asignar tiempo de muestreo de mediciones
0002 FF 10 0020 0001 02 01 1E CC68
1 2 3 4 5 6 7 8
3. Instrucción MODBUS de escritura de un solo byte: 0x10
4. Registro (expresado en 2 bytes) donde se comenzará a escribir, 32 en hexadecimal: 0x0020
5. Cantidad de datos expresado como palabra de 16 bits, en este caso al ser 2 registros, el valor
será 1: 0x0001
131
6. Cantidad de datos en bytes (8 bits): 0x02

7. Datos en bytes que se escribirán, 1 y 30 serán: 0x01 y 0x1E
8. Para finalizar, el CRC de los 6 datos anteriores (9 bytes): 0x CC68
Una vez enviada la petición y procesada por el MedidorE, si todo ha salido bien regresará como
respuesta solo los primeros 6 bytes de la petición más su respectivo valor CRC:
Tabla 5.10. Respuesta en caso OK
FF 10 0020 0001 DD15
El resultado de estas pruebas fue el deseado por lo que la programación de la instrucción 0x10 en
el MedidorE fue correcta.
5.1.4 Prueba de errores MODBUS en el MedidorE

En las comunicaciones Maestro-Esclavos suelen ser comunes los errores ya sea en la transmisión
o en la recepción de los datos, o datos transmitidos correctamente pero no válidos. Para dar robustez
a un sistema será necesario identificar y notificar si es posible del tipo de error detectado. Para este
MedidorE en específico pueden enlistarse los siguientes errores posibles durante el proceso de
comunicación, así como el mensaje de replica que el medidor generará en ciertos casos:
Tabla 5.11. Errores MODBUS durante la comunicación NodoM-Medidor

Error enviado como respuesta Causas posibles
Error de CRC en la petición
No se recibe ningún mensaje de El esclavo a quien se dirige el mensaje no
respuesta está en la red
Se envió mensaje al esclavo 0 (broadcast)
La instrucción que el maestro envía en el
Error 0x01 mensaje no se reconoce por el esclavo
destino
Registro que se pretende leer o escribir no
Error 0x02
es válido (generalmente no existe)
Registro que se pretende escribir no tiene
Error 0x22
permiso
Es necesario aclarar que todos los mensajes de error en la respuesta generada por un medidor
esclavo (de hecho cualquier esclavo trabajando en MODBUS) mostrarán el siguiente formato:
132
Tabla 5.12. Respuesta en caso OK
FF 83 22 D9A0
1 2 3 4
1. Esclavo que responde a un mensaje del maestro (MedidorE 255)
2. Instrucción enviada más el valor 0x80 (0x03 + 0x80) = 0x83
3. Error (en este caso error 0x22 debido a que se trató de escribir en un registro restringido)
4. CRC correspondiente a los 3 bytes anteriores
5.2 Pruebas al NodoM
Al igual que con el MedidorE se necesitará comprobar el adecuado funcionamiento de este

componente. Primero se comprobará su puerto serial RADIO con el cual se comunica con el radio
LoRa para así transmitir y recibir datos con el CMD. Se comprobarán también las funciones
especiales CMD-NodoM que servirán para administrar los datos (números de serie de medidores
agregados) contenidos en la variable llamada lista_verificacion. Y se probará también que pueda
interactuar con un MedidorE conectado por el puerto RS485 leyendo y escribiendo registros
mediante el protocolo MODBUS. Para dichas pruebas se utiliza la misma terminal a PC utilizada
con el MedidorE.
Se mostrarán siete ejemplos consecutivos donde se utilizan las instrucciones CMD-NodoM

explicando su forma de uso, sus parámetros y resultados obtenidos. No se exponen en orden. Un
ejemplo llevará al siguiente.
Se comenzará reseteando al NodoM (instrucción 0x0F), luego se agregará un MedidorE

(instrucción 0x0C), se verificará el MedidorE en base a su número de esclavo (instrucción 0x0B)
y después en base a su número de serie (instrucción 0x0E), se explorará al NodoM (instrucción
0x0A), se dará de baja al medidor previamente agregado (instrucción 0x0D) y finalmente se
cambiará la configuración del radio LoRa al que conecta el NodoM (instrucción 0x00).
5.2.1 Prueba de la instrucción 0x0F: resetear lista_verificacion

Los medidores pueden darse de baja del NodoM uno a uno pero dicha tarea puede resultar tediosa
cuando son muchos los medidores. La instrucción 0x0F tiene la finalidad de eliminar todos los
medidores agregados en la lista_verificacion del NodoM (en este caso el NodoM al que se dirige
el mensaje es aquel conectado al radio LoRa número 0x0002) de una sola vez. La estructura para
esta instrucción es muy sencilla, se explica mediante el siguiente ejemplo:
133
Tabla 5.13. Mensaje para borrar todos los medidores del NodoM 0x0002
0002 01 0F 0000 DB31

1 2 3 4 5
2. El número de esclavo (número del NodoM): 0x01
3. Instrucción: 0x0F
4. Para este instrucción siempre se enviaran dos bytes en ceros: 0x0000
5. Se finaliza con el CRC de los puntos 2 a 4: 0xDB31
Una vez recibido este comando y ejecutada la acción de resetear la lista_verificacion si todo salió
bien el NodoM deberá responder con el mismo mensaje. En la prueba realizada el mensaje de
respuesta fue:
Tabla 5.14. Mensaje de respuesta OK
01 0F 0000 DB31
Como se puede ver el mensaje de respuesta es idéntico al de petición por lo que el resultado fue
el esperado.
5.2.2 Prueba de la instrucción 0x0C: asignar MedidorE al NodoM

Como se explicó en la sección 4.2, los NodoM además de actuar como interface entre la red AMI
(red LoRa) y el Medidor (red RS485) también actúan como un primer concentrador que
almacenará los números de serie de los MedidorE´s a los que conecte haciendo que dichos
MedidorE´s solo puedan funcionar en un único NodoM. Esos números de serie se almacenan en
la lista_verificacion y para hacerlo se tiene la instrucción 0x0C. El proceso debe hacerse
MedidorE por MedidorE. Todos los medidores por defecto vienen con la dirección de esclavo
0xFF (255) por lo que se deberán de agregar inicialmente en esta posición. Una vez agregado un
MedidorE como esclavo 255 se sugiere modificar su número de esclavo (se explica cómo al final
de la sección 5.2.2) sobre todo si se desean agregar más medidores. Para evitar que un mismo
MedidorE se agregue dos veces en el NodoM, esta función antes de agregar al nuevo MedidorE
revisará la lista_verificacion con el fin de detectar si dicho MedidorE ya está dado de alta con
alguno de los 254 números de esclavo disponibles, de ser así devolverá un mensaje de error.
A continuación se muestra como agregar en el NodoM 0x0002 el MedidorE con el número de

serie: “m001XYZ000” (este número de serie expresado en código ASCII hexadecimal es: 0x6D
30 30 31 58 59 5A 30 30 30). El MedidorE por defecto está como el esclavo 255. El mensaje para
darlo de alta se muestra a continuación:
134
Tabla 5.15. Mensaje para agregar el MedidorE m001XYZ000, esclavo 255 en el NodoM 0x0002
0002 01 0C FF 6D 30 30 31 58 59 5A 30 30 30 29D0
1 2 3 4 5 6
3. Instrucción: 0x0C
4. Número de esclavo del MedidorE que será agregado: 0xFF
5. Número de Serie del MedidorE que será agregado: 0x6D 30 30 31 58 59 5A 30 30 30
6. Se finaliza con el CRC total de los puntos 2 a 5: 0x29D0
El NodoM respondió con el siguiente mensaje:

Tabla 5.16. Mensaje de respuesta OK del NodoM
01 0C 0000 DBC1
Los valores 0x01 y 0x0C hacen referencia al esclavo (NodoM) y la instrucción enviada, el valor
0x0000 significa que el medidor fue agregado correctamente, pero si el dato fuera 0xFFFF
significaría que hubo un error ya sea porque el medidor ya existe en el NodoM o por que se le
intento asignar con un número de esclavo restringido (0x00 o 0x01). El parámetro DBC1 es su
respectivo CRC calculado.
5.2.3 Prueba de la instrucción 0x0B: verifica MedidorE por número

de esclavo
Para corroborar que un MedidorE ha sido agregado exitosamente o simplemente para checar de
forma rápida el Número de Serie de algún MedidorE (refiriéndose a él por su número de esclavo)
se creó la instrucción 0x0B. Dicha instrucción solo necesitará saber el número de esclavo del
MedidorE del que se quiere checar y como resultado el NodoM devolverá el número de serie del
MedidorE si es que este existe. Si no existiera en vez de los 10 dígitos de un número de serie se
verán 10 dígitos con cero. A continuación se muestra como verificar el MedidorE esclavo 255
agregado en el NodoM 0x0002 durante el punto anterior.
Tabla 5.17. Mensaje para verificar el número de serie del MedidorE esclavo 255 en el NodoM 0x0002
0002 01 0B 00FF 5A30

1 2 3 4 5
3. Instrucción: 0x0B
135
4. Para esta instrucción se requiere saber únicamente el número de esclavo del MedidorE que
será verificado, en este caso es el 255 (0xFF), pero primero se debe agregar un 0x00,
quedando entonces: 0x00 FF
5. Se finaliza con el CRC de los puntos 2 a 4: 0x5A30
Una vez recibido este comando y ejecutada la acción de checar el MedidorE, si todo salió bien el
NodoM deberá responder con el siguiente mensaje:
Tabla 5.18. Mensaje de respuesta del NodoM, entregando el número de serie del MedidorE solicitado
01 0B 6D 30 30 31 58 59 5A 30 30 30 A14E
Los valores 0x01 y 0x0B hacen referencia al esclavo (NodoM) y la instrucción enviada, el valor
0x6D 30 30 31 58 59 5A 30 30 30 es el Número de Serie del Medidor esclavo 255. El parámetro
DBC1 es su respectivo CRC calculado.
Con la instrucción 0x0B también podrá leerse el número de serie del dispositivo NodoM, el cual
está siempre agregado como el esclavo 0x01, para realizar esto el mensaje de petición será el de la
tabla 5.19 mientras que la respuesta se muestra en la tabla 5.20.
Tabla 5.19. Mensaje para solicitar el número de serie del NodoM 0x0002
0002 01 0B 00 0001 DAB1
Tabla 5.20. Mensaje de respuesta del NodoM, entregando su número de serie
01 0B 4E 4D 30 30 M31 61 62 63 30 30 DBC7
Donde 0x 4E 4D 30 30 M31 61 62 63 30 30 equivale en código ASCII a: “nm001ABC00”. Ahora

bien se puede checar otro número de esclavo para verificar si hay un MedidorE agregado ahí, por
ejemplo se verificará la posición esclavo 100 (0x64), el mensaje de petición es:
Tabla 5.21. Mensaje para solicitar el número de serie del MedidorE 100, si es que existe
0002 01 0B 00 0064 F171
Debido a que no se ha agregado ningún MedidorE esclavo con la dirección 100 la respuesta será:
Tabla 5.22. Mensaje de respuesta del NodoM indicando que no hay MedidorE en la posición 100
01 0B 00 00 00 00 00 00 00 00 00 00 E5BC
Justo como se esperaba se devolvieron 10 dígitos igualados a cero, esta instrucción en el NodoM
se comporta conforme lo esperado.
136
5.2.4 Prueba de la instrucción 0x0E: verifica MedidorE por número

de serie
Esta instrucción tiene un propósito muy similar al de la 0x0B solo que en esta ocasión se buscará
en la matriz lista_verificacion al dispositivo esclavo por su número de serie, devolviendo el
número de esclavo que tiene dicho dispositivo si es que existe. Resulta muy útil para corroborar la
correcta agregación de un MedidorE o para saber el número de esclavo o posición en la
lista_verificacion en donde se ubica el MedidorE deseado. Como ejemplo se realizará la búsqueda
en el NodoM 0x0002 del MedidorE con Número de Serie: “m001XYZ000” (en ASCII
hexadecimal: 0x6D 30 30 31 58 59 5A 30 30 30). El proceso será:
Tabla 5.23. Mensaje para verificar el número de esclavo del MedidorE “m001XYZ000” en el NodoM 0x0002
0002 01 0E 6D 30 30 31 58 59 5A 30 30 30 6D5F
1 2 3 4 5
3. Instrucción: 0x0E
4. Número de serie del MedidorE que será verificado: 0x6D 30 30 31 58 59 5A 30 30 30
5. Se finaliza con el CRC de los puntos 2 a 4: 0x6D5F
Tabla 5.24. Mensaje respuesta de parte del NodoM 0x0002
01 0E 00FF 5B20
Donde 0x01 y 0x0E hacen referencia a esclavo e instrucción, el siguiente byte siempre será 0x00
mientras que el segundo es el número de esclavo del MedidorE que deseamos conocer: 00xFF. Al
final el CRC del mensaje respuesta 5B20.
Si el MedidorE que se busca por número se serie no existe la respuesta que se obtendrá es:
Tabla 5.25. Mensaje de respuesta del NodoM al no encontrar el número de serie
01 0E FFFF AB61
Donde 0xFFFF indica que el MedidorE buscado no existe en la lista_verificacion del NodoM.
5.2.5 Prueba de la instrucción 0x0A: explorar NodoM

Si se requiere saber los datos actuales de la lista_verificacion, se tendrá que ocupar la instrucción
0x0A. Dicha instrucción devolverá tres parámetros: El número de serie del NodoM, la cantidad de
137
esclavos (NodoM + n MedidorEs) que tiene agregados y una máscara para indicar las posiciones
ocupadas por los dispositivos esclavos. Se mostrará esta instrucción explorando el NodoM 0x0002
sobre el cual ya se ha agregado un MedidorE en los pasos anteriores.
Tabla 5.26. Mensaje para ver la lista_verificacion del NodoM 0x0002

0002 01 0A 0000 DA21
1 2 3 4 5
3. Instrucción: 0x0A
4. Para esta instrucción no se requieren parámetros adicionales, aun así será obligatorio
continuar con dos bytes en ceros: 0x0000
5. Se finaliza con el CRC de los puntos 2 a 4: 0xDA21
Como respuesta se tiene:

Tabla 5.27. Mensaje de respuesta del NodoM mostrando el contenido en su lista_verificacion
01 0A 4E 4D 30 30 31 61 62 63 30 30 02 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 117C
Donde 0x01 y 0x0E hacen referencia a esclavo e instrucción, los siguientes 10 bytes son el número
de serie del NodoM 0x0002. El siguiente valor indica cuantos esclavos hay agregados en la
lista_verificacion, en este caso son 00x02 (2). Los siguientes 32 bytes o mejor dicho 256 bits
forman una máscara para identificar las posiciones (números de esclavo) ocupadas tanto por el
NodoM como por los MedidorE’s. El primer byte tienen un 0x02, el cual en binario es
‘00000010’, de esta manera se indica que la primer posición (bit0=0) está vacía, la segunda (bit1=1)
está ocupada siempre por el NodoM y las siguientes están vacías así hasta llegar al byte 32 cuyo
valor es 0x80 (en binario ‘10000000’) y donde puede verse que el último bit (bit8, equivalente a la
posición 255=1) está ocupado por un esclavo el cual si es un MedidorE. Al final el CRC del
mensaje respuesta 117C. Esta instrucción parece compleja de analizar, pero en realidad será
analizada por el CMD, que mediante un algoritmo sencillo podrá interpretarla rápidamente y saber
que lugares están ocupados o disponibles para agregar nuevos medidores.
5.2.6 Prueba de la instrucción 0x0D: eliminar MedidorE del NodoM

Supóngase el caso de que se quiere eliminar solo un MedidorE del NodoM 0x0002, ya sea porque
dicho MedidorE será remplazado o el usuario ha dado de baja su servicio con la compañía de luz.
Para dar de baja a un MedidorE de un NodoM está la instrucción 0x0D. El mensaje es el siguiente:
138
Tabla 5.28. Mensaje para dar de baja al MedidorE 255, número de serie “m001XYZ000”, del NodoM 0x0002
0002 01 0D 00FF 5BD0

1 2 3 4 5
3. Instrucción: 0x0D
4. Número de esclavo del MedidorE que será eliminado, en este caso es el 255 (0xFF), pero
primero se antepondrá un 0x00, quedando entonces: 0x00 FF
5. Se finaliza con el CRC de los puntos 2 a 4: 0x5BD0
Una vez recibido este comando y ejecutada la acción de eliminar el medidor, si todo salió bien el
NodoM deberá responder con el siguiente mensaje:
Tabla 5.29. Mensaje de respuesta OK del NodoM
01 0D 0000 1B90
Los valores 0x01 y 0x0D hacen referencia al esclavo (NodoM) y la instrucción enviada; el valor
0x0000 significa que el MedidorE fue eliminado correctamente, pero si no hubiera sido así el valor
obtenido sería 0xFFFF alertándonos de un error (en este caso el error se da por tratar de eliminar
los registros en posiciones restringidas como la 0x00 y la 0x01). El dato 1B90 es el CRC de la
respuesta.
5.2.7 Prueba de la instrucción 0x00: reconfiguración del radio LoRa

Durante el trabajo normal de una AMI pueden requerirse de ciertos ajustes o modificaciones en los
componentes de la red, para este caso se creó la instrucción 0x00 que permite enviar un mensaje
de reconfiguración para el radio LoRa RF1276T (proceso explicado en el Apéndice F.3.1)
encargado de enlazar al NodoM con el CMD. Dicho mensaje consta de 23 bytes con la información
necesaria para configurar todos sus parámetros como son las velocidades de transmisión, el canal
de trabajo, la frecuencia, la velocidad de transmisión y más importante aún cambiar su número ID
o el número de red en la cual trabajará. Este mensaje de configuración al igual que todos los demás
mensajes hacia el NodoM deberá ir acompañado de datos adicionales:
Tabla 5.30. Mensaje para configurar el radio LoRa del NodoM 0x0002
0002 01 00 AF AF 00 00 AF 80 01 0C 04 00 E4 C0 26 0B 02 07 00 03 01 07 87 0D 0A 964D
1 2 3 4 5
2. El número de esclavo (número esclavo del NodoM): 0x01
3. Instrucción: 0x00
139
4. Mensaje de configuración con los parámetros deseados como es explicado en el Apéndice

F.3.1: 0x AF AF 00 00 AF 80 01 0C 04 00 E4 C0 26 0B 02 07 00 03 01 07 87 0D 0A
5. Finalmente el CRC de los puntos 2 a 4: 0x964D
Al enviar este comando, el NodoM 0x0002 identificará la instrucción y tomará solo los datos
necesarios (los del punto 4) para así devolverlos al radio y poder llevar a cabo el proceso de
reconfiguración. Si el proceso de reconfiguración se realizó correctamente no debería verse ningún
mensaje ya que al cambiar la configuración pudieron modificarse parámetros como la frecuencia
o la velocidad de transmisión serial, haciéndola entonces incompatible con el radio LoRa del CMD.
Cuando el mensaje de configuración es erróneo, por ejemplo modificando el byte 21 (ver CS en el

Apéndice F.3.1), 0x87 por 0x07:
Tabla 5.31. Mensaje erróneo para configurar el radio LoRa del NodoM 0x0002
0002 01 00 AF AF 00 00 AF 80 01 0C 04 00 E4 C0 26 0B 02 07 00 03 01 07 07 0D 0A CBA7
1 2 3 4 5
El NodoM 0x0002 devolverá 23 bytes en ceros.

Tabla 5.32. Mensaje de error al tratar de reconfigurar el radio LoRa del NodoM 0x0002
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
5.3 Pruebas a la red LoRa

En la sección Apéndice F.2 se explican los pasos a seguir para configurar a los radios RF1276T los
cuales conformarán a la red LoRa que enlazará al CMD con los NodoM. Las pruebas a dicha red
se podrán dividir en dos:
 Pruebas de transmisión de datos
 Pruebas de rango de transmisión alcanzado
5.3.1 Pruebas de transmisión de datos

Una vez programados el radio Central (para el CMD) y los 2 radios Nodo (para los NodoM) ya se
dispondrá de una red LoRa (red Net_ID=1 configuarada en todos los radios). Por lo que pueden
entonces seguirse los siguientes pasos:
 La forma más rápida de verificar la red es conectando los tres radios a una PC mediante los
adaptadores USB-serial mencionados en el Apéndice F.1, la conexión física para configurar a
los RF1276T al adaptador USB se muestra en la figura F.4 del Apéndice F.2.
140
 Como se muestra en la figura 5.3, los radios se pueden probar en una misma PC, y la única
diferencia que se mostrará será el puerto de conexión que vincula a cada uno con RF Tool, en
este caso los puertos son COM5 como nodo central Node ID=1, COM6 como Node ID=3 y
COM7 como Node ID=2.
Figura 5.3. Tres radios conectados con sus adaptadores USB en la misma PC
 Para poder utilizar la red LoRa, la conexión del módulo Central se dejará igual a la mostrada en
la figura F.4, mientras que los módulos Nodo deberán de modificarse (figura 5.4) desconectando
el 3er pin (pin EN), al hacer esta desconexión este pin recibirá un nivel “alto” o 1 lógico gracias
a que cuenta con una resistencia de “pull up”. Cuando ponemos al pin EN en “1”, el RF1276T
quedará en estado CAD (estado en espera de recibir un mensaje, en ese estado no puede
transmitir). Cuando este radio Central trabaje en el CMD el pin EN será controlado por una
salida GPIO dedicada. Mientras el RF1276T este en estado CAD, el LED azul estará
parpadeando (es decir previo a recibir un mensaje).
Figura 5.4. Al desconectar el pin EN, el RF1276T entrará en modo CAD, esto solo se utilizará en los módulos Nodo
 Para probar la red LoRa, se utilizará la terminal serial SSCOM32 desde la cual se enviará un
mensaje hexadecimal a través del módulo Central, por ejemplo el paquete 0x 00 02 33 44 55 66
77 88. Los primeros dos bytes del paquete (0x 00 02) son la dirección (Node ID=2) del módulo
Nodo al que se enviarán los datos 0x 33 44 55 66 77 88. Recordando que el módulo Central se
conectó en el puerto COM5 de la PC y el Nodo 2 en el puerto COM7 (ver figura 5.5).
Puerto serie
vinculado al Nodo
Central
Node ID (2) del Nodo al

que se envían los datos Datos a enviar
Figura 5.5. Enviando “00 02 33 44 55 66 77 88” desde el módulo Central (en COM5) al Nodo 2
141
 Realizado lo anterior se podrán ver los datos “33 44 55 66 77 88” desde su respectiva terminal
SSCOM32 recibidos solo por el módulo Nodo 2 el cual está vinculado al puerto COM7 (figura
5.6). Por su parte el módulo Nodo 3 vinculado al COM6 no deberá recibir nada (figura 5.7).
Figura 5.6. Recibiendo “33 44 55 66 77 88” con el Nodo 2 en el COM7
Puerto serie
vinculado al Nodo 3
Figura 5.7. El Nodo 3 en el COM6 no deberá recibir ningún dato
 Ahora enviando desde el módulo Central el paquete “00 03 22 22 22 22 22 22 22 22 02” (ver

figura 5.8). Esta vez el valor inicial “00 03” hace referencia al Nodo 3.
Datos a enviar
Node ID del Nodo 3
Figura 5.8. Enviando “22 22 22 22 22 22 22 22 02” al Nodo 3 desde el módulo Central en el COM5
142
 El Nodo 3 vinculado al COM6 será el único en recibir lo datos “22 22 22 22 22 22 22 22 02”

(figura 5.9) mientras que la terminal COM7 vinculada al nodo 2 no debe recibir nada (figura
5.10). En aplicaciones como la Raspberry Pi después de que el módulo Nodo ha recibido los
datos del módulo Central, generalmente el pin EN del módulo Nodo se pone en “0” lógico para
enviar ahora datos al módulo Central. Cuando el proceso termina, el pin EN de nuevo se regresa
a “1” lógico y entonces el módulo RF1276T pasará al estado CAD.
Datos recibidos
Puerto serie
vinculado al Nodo 3
Figura 5.9. Recibiendo “22 22 22 22 22 22 22 22 02” con el Nodo 3 en el COM6
Figura 5.10. El Nodo 2 en el COM6 no debe recibir nada en esta ocasión
A partir de la prueba anterior, se tiene a los RF1276T trabajando como una red de topología estrella.
El módulo Central despierta a los módulos Nodo a través del ID de nodo. El módulo Nodo está
siempre en el estado CAD. En estado CAD, un RF1276T presentará un bajo consumo de energía.
Por lo tanto el RF1276T es adecuado para aplicaciones energizadas por batería.
Adicionalmente puede corroborarse que en condiciones ideales el tiempo aproximado en recibirse

un mensaje una vez transmitido por un RF1276T es siempre de 2 segundos, tal como se configuró
(ver tabla F.1 del Apéndice F.2) por lo tanto un mensaje transmitido por el CMD, recibido,
procesado y contestado por el NodoM toma un tiempo máximo de 4.5s. Pero entre mayor es la
distancia y la interferencia entre CMD y NodoM será más difícil que el mensaje llegue a su destino,
por lo que será necesario repetirlo. En las pruebas realizadas a distancia máxima fue necesario
143
reenviar un mismo mensaje hasta 5 veces o incluso más, situación similar al momento de generar
la respuesta; en estos casos el tiempo total de una petición-respuesta llegó a tardar hasta 20s.
No se pudieron hacer pruebas de mayor precisión para medir el tiempo transmisión-recepción

debido a la falta de equipo y a que por la naturaleza de las AMI el tiempo de respuesta no precisa
de ser tan rápido.
5.3.2 Pruebas de rango de transmisión alcanzado

Las especificaciones de los fabricantes dicen que los radios LoRa pueden llegar hasta a 5Km de
alcance, siempre y cuando esto se haga a línea de vista entre transmisor y receptor (sin
interferencias o cuerpos de por medio), en ambientes de poca o nula interferencia electromagnética,
con antenas de alta ganancia (las de mejor calidad que sea posible) y transmitiendo pocos datos a
la menor velocidad permitida por el radio; es decir en condiciones ideales.
En la práctica el alcance obtenido fue mucho menor, y aunque son muchas las variables que
intervienen, se hicieron unas cuantas pruebas variando principalmente la antena y el lugar. La
cantidad de datos y la velocidad de transmisión no se variaron debido a que esto implicaría cambiar
las configuraciones de los puertos seriales en el CMD y en el NodoM.
Para esta etapa de pruebas se utilizó a los radios conectados a PC tal como se hizo en la sección
5.3.1 escribiendo datos aleatorios a través de las terminales SSCOM32 y esperando verlos en una
terminal igual pero en otra PC. Mientras un usuario monitoreaba la PC con el radio central (ubicada
en las instalaciones de SEPI Eléctrica dentro del edificio Z4) el otro se desplazaba con una
computadora portátil y el radio nodo. El punto límite se consideró una vez que se dejaban de
visualizar los datos en alguna de las PCs, la comunicación entre los usuarios de la PC se llevó por
medio de llamadas por teléfono celular.
Las pruebas se llevaron a cabo en la Unidad Profesional Adolfo López Mateos, Zacatenco del
Instituto Politécnico Nacional y se mostrarán las zonas y alcances obtenidos por medio de imágenes
de “google maps” utilizadas como referencia.
Las pruebas con mucha interferencia se hicieron entre los edificios de ESIME, básicamente a lo
largo del edificio Z el cual como se puede apreciar en las imágenes 5.11 y 5.12 es una construcción
larga con muchos salones, muros, columnas metálicas y demás mobiliario propio de una
institución, adicionalmente un radio se encontraba en el tercer piso mientras el otro se desplazaba
sobre el nivel del suelo. En el caso de las antenas de largo alcance se caminó hacia las calles de la
colonia Lindavista, la cual es una zona residencial actualmente llena de casas y construcciones. Por
lo todo lo anterior puede decirse que son casos reales de trabajo para los radios LoRa.
La pruebas con poca interferencia se hicieron partiendo del mismo punto que en las anteriores pero
está vez el receptor se fue desplazando a lo largo de las áreas verdes (ver imagen 5.12) , donde
144
teóricamente la interferencia es mucho menor ya que solo hay vegetación en vez de construcciones
y la línea de vista es considerablemente mejor.
Edificio Z4,
3er piso.
SEPI
Figura 5.11. Mapa de donde se realizaron las pruebas de alcance con los radios LoRa
Figura 5.12. Vista aérea real de la zona de pruebas obtenida desde www.google.com.mx/maps
Se utilizaron dos tipos de antenas diferentes, de baja y de alta ganancia (ver detalles en Apéndice
B.9). En base a lo anterior puede resumirse que las pruebas de alcance realizadas para la red LoRa
utilizada se dividen en cuatro, y cuyos resultados obtenidos se exponen en las figuras 5.13 a 5.16
y se resumen en la tabla 5.4.
145
Figura 5.13. Alcance obtenido con antena de baja ganancia y mucha interferencia: 248m
Figura 5.14. Alcance obtenido con antena de alta ganancia y mucha interferencia: 351m
146
Figura 5.15. Alcance obtenido con antena de alta ganancia y mucha interferencia: 385m
Figura 5.16. Alcance obtenido con antena de alta ganancia y poca interferencia: 491.6m
Tabla 5.33. Alcance obtenido según las condiciones de la prueba

Ganancia Interferencia Distancia Imagen de
de antena del entorno alcanzada referencia
Baja Mucha (construcciones) 248 m 6.14
Baja Poca (vegetación) 351 m 6.15
Alta Mucha (construcciones) 385 m 6.16
Alta Poca (vegetación) 491 m 6.17
147
5.4 Pruebas del servidor FTP
En el Apéndice E.1.10 se explicaron los pasos a seguir para configurar el servidor FTP vsftpd en
la Raspberry Pi, esto con el fin de crear un sistema de almacenamiento y acceso de archivos remotos
para nuestro CMD. Para probar dicho servidor se hará uso de una PC que esté conectada a la
misma red que el CMD y un programa “cliente FTP” que nos permita acceder y ver los archivos
de un servidor FTP. En la web se podrán encontrar varios programas cliente FTP, para esta sección
se decidió utilizar “FileZilla”.
Utilizar “FileZilla” como medio de acceso a servidores FTP es una tarea muy sencilla basta con
abrir el programa e ingresar correctamente (ver figura 5.17) los siguientes tres datos generados
previamente en el Apéndice E.1.5:
 Servidor: 192.168.100.6 Aquí va la dirección la dirección IP (del CMD) en caso de

que el servidor esté en la misma red como en este caso. En caso de que el servidor este en
internet en esta sección se escribirá la dirección URL.
 Nombre de Usuario: CMD_00 Como se explica en la sección 2.3.4 un servidor FTP

puede tener múltiples cuentas de usuario.
 Contraseña: raspberry También de carácter obligatorio para cualquier cuenta FTP.
Figura 5.17. Vista del panel superior de “FileZilla” donde se ingresan servidor, usuario y contraseña
Si los datos son correctos y el programa vsftpd está funcionando bien en la Raspberry Pi podremos
ingresar con FileZilla al directorio creado en el Apéndice E.1.5. Una vez dentro del servidor FTP
del CMD FileZilla mostrará en su interfaz (ver figura 5.18) las siguientes ventanas:
1. Estado de la conexión
2. Directorio de la PC de donde se pueden intercambiar archivos con el servidor FTP
3. Directorio del servidor FTP CMD_00
4. Archivos del lado de la PC
5. Archivos del lado del servidor FTP
6. Ventana de archivos intercambiados entre PC y servidor FTP
148
2 3
3
4 5
Figura 5.18. Vista de “FileZilla” mostrando las ventanas para compartir archivos entre PC y servidor FTP
5.5 Pruebas del CMD (datalogger)
El programa datalogger.py estará trabajando continuamente en el sistema operativo de la

Raspberry Pi (CMD) por lo que desde este mismo podrán ser visualizados los mensajes que genera
después de cada medición y registro de datos.
 Primero deberá ejecutarse el programa “LXTerminal” en Raspbian (el sistema operativo de

la Raspberry Pi), y una vez abierto se mandará a ejecutar datalogger.py (ver figura 5.19)
tecleando el siguiente comando, cuyos parámetros se explican enseguida:
sudo python datalogger.py
Para entender los parámetros usados en la línea anterior:
-python = se debe especificar que compilador ejecutará el programa llamado

-dstalogger.py = directorio y nombre del programa a ejecutar
149
Figura 5.19. Ejecución de datalogger.py desde “LXTerminal”
 El programa comenzará a comunicarse con cada MedidorE que esté registrado en

lista_medidores.txt, y en la pantalla de “LXTerminal” se mostrarán todos los datos
obtenidos, así como las acciones que se estén realizando y la hora de dichos eventos, la
figura 5.20 muestra detalladamente los datos mostrados en pantalla cuando el programa
datalogger.py está funcionando:
Intentos para que el
MedidorE respondiera
Número de Serie
Esclavo dentro del NodoM
Estado (conectado
o desconectado)
Voltaje instantáneo
Corriente instantánea
Frecuencia instantánea
Factor de potencia
THD instantáneo instantáneo
instantánea Tiempo de toma de mediciones
Potencia Activa acumulada
Potencia Reactiva acumulada
THD máximo desde la
última medición Hora en la que
registró la medición
tomada
Figura 5.20. “LXTerminal” mostrando los datos obtenidos después de comunicarse con el MedidorE
“m001XYZ000”
Después de comprobar en las secciones anteriores el correcto funcionamiento de los componentes

MedidorE, NodoM y CMD, así como las comunicaciones entre estos, se ejecutó el programa
datalogger.py y se dejó en funcionamiento junto con los demás componentes de la AMI. El
resultado obtenido fue un archivo de mediciones llamado: m001XYZ000_1_2016.txt, es decir que
se estuvo monitoreando durante todo el mes de enero del 2016 al MedidorE con número de serie
m001XYZ000.
A continuación se muestran una serie de gráficas obtenidas de los tres tipos de datos registrados en
el archivo m001XYZ000_1_2016.txt: energía activa (KWh), energía reactiva (KVArh) y THD
máximo entre cada medición. Las gráficas se muestran en diferentes periodos de tiempo: por día
(graficando el 1 de Enero de 2016) y por mes (graficando Enero de 2016). Se muestran también
los datos reales obtenidos cada 10 minutos y posteriormente gráficas de barras con los datos
promediados (en horas o días según el caso).
150
Enero 2016
0.5
Figura 5.21. Gráfica de KWh medidos en un día (1 de Enero del 2016), muestras cada 10 minutos
0.45
Enero 2016
0.4
0.35
Energía Rectiva consumida (KVArh)
0.3
Energía Activa consumida (KWh)
0.25
1.5
0.2
1
0.15
0.1
0.5
0.05
0 0
00 500 5 1000 101500 2000 15 2500 20 3000 3500
25 4000 30
tiempo (días)
tiempo (dias)
Figura 5.22. Gráfica de KWh medidos durante un mes (Enero del 2016), muestras cada 10 minutos
151
1 enero 2016
4
3.5
2.5
1.5
0.5
0
5 10 15 20
tiempo (hrs)
Figura 5.23. Energía activa medida cada hora del 1 de enero del 2016
Enero 2016
60
50
40
30
20
10
0
0 5 10 15 20 25 30
tiempo (días)
Figura 5.24. Energía activa medida cada día del mes de Enero del 2016
152
1 de Enero 2016
0.4
0.35
0.3
0.25
0.2
0.15
0.1
0.05
0
0 5 10 15 20
tiempo (horas)
Figura 5.25. Gráfica de KVArh medidos en un día (1 de Enero del 2016), muestras cada 10 minutos
Enero 2016
0.5
0.45
0.4
0.35
0.3
0.25
0.2
0.15
0.1
0.05
0
0 5 10 15 20 25 30
tiempo (dias)
Figura 5.26. Gráfica de KVArh medidos en un mes (Enero del 2016), muestras cada 10 minutos
153
1 enero 2016
1
0.9
Energía Reactiva consumida (KVArh)
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
5 10 15 20
tiempo (hrs)
Figura 5.27. Energía reactiva medida cada hora del 1 de enero del 2016
Enero 2016
14
Energía Reactiva consumida (KVArh)
12
10
0
5 10 15 20 25 30
tiempo (días)
Figura 5.28. Energía reactiva medida cada día del mes de Enero del 2016
154
1 de Enero 2016
22
20
18
16
14
THDmax/10min (THD/t)
12
10
0
0 5 10 15 20
tiempo (horas)
Figura 5.29. Gráfica de THD máximo entre cada medición durante un día (1 de Enero del 2016), muestras cada 10
minutos
Enero 2016
22
20
18
16
14
THDmax/10min (THD/t)
12
10
0
0 5 10 15 20 25 30
tiempo (dias)
Figura 5.30. Gráfica de THD máximo entre cada medición durante un mes (Enero del 2016), muestras cada 10
minutos
155
1 enero 2016
20
% THDmax/10min (THDmax/t)
15
10
0
5 10 15 20
tiempo (hrs)
Figura 5.31. THD máximo detectado cada hora del 1 de Enero del 2016
1 de Enero 2016
25
20
% THDmax/10min (THDmax/t)
15
10
0
5 10 15 20 25 30
tiempo (días)
Figura 5.32. THD máximo detectado cada día de Enero del 2016
156
Capítulo 6: Conclusiones y
trabajos futuros
6.1 Conclusiones
Basándose en los objetivos planteados en la sección 1 y al trabajo realizado a lo largo de esta tesis
pueden obtenerse las siguientes conclusiones:
 MedidorE: El uso del MedidorE cumplió los objetivos en cuanto a la generación de valores
aleatorios instantáneos y acumulativos emulando a un medidor digital real, gracias a este
dispositivo las mediciones necesarias para probar al CMD y a todos los demás componentes de
la AMI propuesta pudieron ser generadas durante 30 días consecutivos sin perder datos a pesar
de eventuales interrupciones de energía.
 NodoM: El desarrollo del NodoM como primer etapa para concentrar de medidores, así como
como nodo de red dentro de la AMI enlazando una red LoRa por un lado y una red RS485
MODBUS por el otro pudo funcionar de la forma deseada. Todas las funciones especiales que
se le programaron al NodoM funcionaron correctamente quedando así el sistema listo para el
posterior desarrollo de un programa adicional para el CMD mediante el cual se puedan realizar
cambios de configuración de la AMI de forma automatizada a través de estas funciones.
 CMD: Durante la implementación del Concentrador de Medidores Digitales o CMD como parte
central de la AMI propuesta se pudieron ejecutar todas sus tareas de monitoreo de manera
157
automatizada, remota y sin intervención, por lo que cumplió todas las expectativas además de
dar pie a nuevas ideas y propuestas adicionales para continuar e implementar tareas y mejoras
en la AMI.
 Sistemas de comunicaciones: La red inalámbrica de largo alcance LoRa y la red alámbrica

RS485 con protocolo MODBUS, se comportaron de forma eficiente y sin fallos al momento de
comunicar a todos los dispositivos que forman a la AMI propuesta y desarrollada en esta tesis.
 Sistema Administrador: La capacidad de visualizar los procesos ejecutados por el CMD de

manera remota y en tiempo real a través del Sistema Administrador durante los 30 días de
prueba demuestran la versatilidad de todos los prototipos desarrollados en esta tesis. Esta
capacidad facilitó de manera exitosa cumplir los objetivos plateados para el Sistema
Administrador.
 Después de integrar todos los componentes (MedidorE, NodoM, CMD, Sistema

Administrador y sistemas de comunicaciones) dentro de la AMI propuesta y verificar el
correcto funcionamiento de cada uno de manera individual se ejecutó el programa
datalogger.py, la obtención de un archivo de loggeo o mejor dicho de registro de mediciones
durante 30 días consecutivos demuestra el buen funcionamiento de todos los componentes en
conjunto y por lo tanto de la AMI.
6.2 Aportaciones
Tras la culminación de este trabajo de tesis las aportaciones realizadas se enlistan de la siguiente
manera:
 Se creó un dispositivo que emula a un medidor digital y que se enfoca en la capacidad de

interactuar en una AMI, permitiendo la lectura de datos, ajustes de configuraciones y corte y
desconexión de manera remota, así como los algoritmos necesarios para trabajar en una red
multidispositivos y pueda así ser conectado junto a otros medidores en un gabinete o estructura
similar.
 Se creó un dispositivo capaz de agrupar a varios medidores digitales con el fin de concentrarlos
en gabinetes o estructuras similares, además de funcionar como Gateway entre una red
alámbrica de medidores y una red inalámbrica de largo alcance.
 Se creó un concentrador de medidores digitales con capacidad teórica de concentrar a miles de

medidores, guardar sus datos y posibilidad de reconfigurarlos. Además este concentrador
presenta una conexión rápida y eficiente a una red informática por medio de la cual un usuario
puede acceder a la AMI y tomar control total de esta.
158
 Se realizaron y probaron los algoritmos necesarios para el control de una red multidispositivos
con partes inalámbricas e inalámbricas. En esta parte resaltó la implementación de una red
inalámbrica punto a punto y de largo alcance.
 Finalmente se logró crear todo un sistema AMI capaz de ser monitoreado y controlado en tiempo
real desde una red informática que bien puede ser parte de una Intranet privada o incluso
Internet.
6.3 Trabajos futuros

En base a las debilidades encontradas y a nuevas perspectivas visualizadas durante el desarrollo
de este trabajo de tesis se mencionan algunas sugerencias para trabajos a futuro con el fin de
mejorar o complementar esta tesis.
Implementar un medidor digital real

El medidor digital implementado en esta tesis fue en realidad un emulador el cual generaba datos
ficticios de mediciones ya que el objetivo principal fue el de trabajar con dichos datos. Como
propuesta se plantearía implementar un medidor digital real capaz de obtener verdaderos datos de
mediciones eléctricas y al cual se le puedan anexar las funciones programadas en el MedidorE con
la finalidad de que pueda ser integrado en la AMI desarrollada.
Implementar un sistema automático de configuración de la AMI

Una de las tareas más interesantes para este proyecto es que el CMD pudiera configurar a todos
los elementos de la AMI es decir radios LoRa, NodoM y MedidorEs de manera remota y
automatizada; por esta razón se crearon una serie de instrucciones especiales para el NodoM, solo
faltaría crear un programa en Python capaz de leer un archivo de configuración en base al cual el
CMD haga todas las configuraciones, cambios y ajustes pertinentes en cada elemento de la AMI.
Aumentar las capacidades del CMD

Mientras que con un NodoM se pretende concentrar en un solo punto desde uno hasta un máximo
de 254 MedidorEs, con un CMD teóricamente se podrían conectar hasta 65,534 NodoM pero en
un área geográfica que cubre un radio de cientos de metros e incluso kilómetros gracias a la
tecnología de radiocomunicaciones punto a punto LoRa. Con posibilidades de hasta 254
Medidores por NodoM puede estimarse en 16,646,144 MedidorEs como máximo por CMD. Sin
159
duda tener una capacidad tan grande de manejo de dispositivos finales para un solo concentrador
CMD parece ser un tanto complicada y aunque la red LoRa lo permite en sus configuraciones, es
la misma tecnología de LoRa la que delimita el número máximo de dispositivos finales que en este
caso serían NodoM.
Básicamente el factor que limita el número de dispositivos en una misma red LoRa es la velocidad
de transmisión de datos ya que en las pruebas realizadas (ver sección 5.3.2, tabla 5.4) el tiempo
promedio en enviar una petición desde el CMD para tomar lecturas de un solo Medidor, y recibir
la respuesta generada por el NodoM ronda en los 4.5 segundos, con esta velocidad apenas podrán
monitorearse cerca de 13 Medidores por minuto y si la toma de muestras de cada Medidor
pretenden hacerse cada 10 minutos no podrían tomarse los datos de más de 130 medidores, y eso
sin considerar algún tipo de error que provoque la retransmisión del mensaje de petición hasta que
se reciba la respuesta adecuada lo cual prolongará aún más el tiempo.
Hay dos opciones posibles para incrementar el número de dispositivos:
1. Juntando solo los valores de las principales mediciones (KWh, KVArh, etc.) de cada
medidor así como también juntar los datos de varios medidores, todo en un solo mensaje
(el cual puede tener un máximo de 256 bytes), de esta manera podría agilizarse la trasmisión
de datos y aumentar el número de MedidorEs monitoreados.
2. El CMD cuenta con un solo puerto serial el cual se utilizó para conectar con la red LoRa
en esta tesis, pero de fábrica la Raspberry Pi 2 cuenta con 4 puertos USB y en cada puerto
puede utilizarse un convertidor USB-serial, de esta manera gracias a la capacidad
multitareas y al sistema operativo de la Raspberry Pi podrían manejarse 4 redes LoRa extra
de manera independiente e incrementar por 5 la cantidad de Medidores a monitorear por
un único CMD.
Con los puntos anteriores los 130 medidores estimados a leerse en un lapso de 10 minutos podrían
fácilmente superar los mil, todo dependerá de los algoritmos que se implementen para llevar a cabo
dicha optimización.
Implementar una base de datos

El programa datalogger.py hasta el final de este trabajo de tesis almacena los datos de mediciones
en un archivo de texto con extensión “txt”. Esta fue una manera práctica de implementar un
datalogger pero en un sistema de mediciones real y más aun tratándose de una AMI, es casi
indispensable que los datos obtenidos se guarden en archivos de bases de datos para que de esta
manera puedan ser transferidos desde el concentrador principal como actualizaciones de una gran
base de datos que estará en el centro de control o sistema administrador de la AMI.
160
Dicho lo anterior se propone como trabajo a futuro guardar los datos de mediciones en archivos de
bases de datos como podrán ser MySQL o algún similar dependiendo de la plataforma que se elija
como software de base de datos.
Implementar un sistema de monitoreo WEB

Hasta el final de este trabajo los datos de mediciones obtenidos solo pueden verse si se abre
directamente el archivo correspondiente, lo ideal sería programar una interfaz que permita la
visualización directa de estos datos y que además sea capaz de mostrarlos por día, semana o mes.
La interfaz aquí planteada debería ser una página web ya que permitiría ser visualizada y abierta
desde múltiples dispositivos. Además dicha interfaz web debería permitir elegir que medidor de
todos los que tiene la AMI sea monitoreado, y ver tanto sus datos almacenados como sus
mediciones instantáneas.
Implementar un sistema de seguridad informática

En este trabajo se cumplieron los objetivos de conectividad y monitoreo de los componentes de
una AMI conectados dentro de una red informática, sin embargo un punto que no se tocó una vez
cumplidos los objetivos fue el de desarrollar sistemas de encriptación de datos para los archivos
de mediciones. Además se utilizó un servidor FTP el cual no precisa de ser el servidor de
transferencia de archivos más seguro. Otros protocolos como SFTP que se usan dentro de
conexiones tipo SSH, permitirían una seguridad informática mucho mayor y por lo que esta tarea
se sugiere como trabajo a futuro.
161
162
Concentrador de medidores digitales para sistema de mediciones remotas Referencias
Referencias
[1] Rolando Nieva Gómez, “Red Eléctrica Inteligente: Oportunidades para la Innovación”, Mesa Redonda:
“La investigación en energía para el futuro de México: Aspectos relacionados con energía eléctrica”,
Instituto de Investigaciones Eléctricas; 4 abril 2013.
[2] Ramyar Rashed Mohassel, “Application of Advanced Metering Infrastructure in Smart Grids”, 2014
22nd Mediterranean Conference on Control and Automation (MED) University of Palermo. June 16-
19, 2014. Palermo, Italy
[3] NIST Framework and Roadmap for Smart Grid Interoperability Standards, National Institute of
Standards and Technology, Release 3.0, Sep. 2014.
[4] Fuentes V. José G., ¨Propuesta de AMI para Smart Grid’s utilizando una red LoRa¨, XV Congreso
Nacional de Ingeniería Electromecánica y de Sistemas. Instituto Politécnico Nacional. 19-23 de
Octubre 2015.
[5] García-Hernández J., ¨Recent progress in the implementation of AMI projects: Standards and
communications technologies¨, International Conference on Mechatronics, Electronics and
Automotive Engineering. 2015.
[6] Baldiosera Marroquín Abraham, “Diseño de Medidor Inteligente e Implementación de Sistema de

Comunicación Bidireccional”, Instituto Politécnico Nacional, Escuela Superior de Ingeniería
Mecánica y Eléctrica, Sección de Estudios de Posgrado e Investigación, Tesis, Diciembre 2013.
[7] J. Hiscock and D.J. Kang, “Spotlight on Advanced Metering Infrastructure”, AMI Case Book ver. 1.3,
ISGAN-International Smart Grid Action Network, Oct. 2013.
[8] SMSIP Ontario Smart Metering System Implementation Program, IESO presentation, Toronto, Ontario,
Apr. 2007.
[9] Q. Ding, “Dutch Advanced Metering Infrastructure”, MSc Thesis, Dept. System and Network Eng.,
University of Amsterdam, 2012.
[10] BWP, “Smart Grid Program”. [On-line]. Disponible en:

https://www.smartgrid.gov/project/burbank_water_and_power_smart grid_program
[11] J. Cunliffe, “Are you customer ready? Preparing for smart meter deployment and the mobile market”,
IBM presentation, September 2014.
[12] CFE-División de Distribución Baja California, “Medición de energía con tecnología AMI en la división
Baja California”, en CFE, Tijuana, Abril 2008. [citado febrero 2016] Disponible en:
http://es.slideshare.net/CICMoficial/infraestructura-avanzada-de-medicin-reunin-regional-en-
mexicali
[13] CFE-División Valle de México centro, “Retos e Iniciativas para las Tecnologías de Información y
Comunicaciones en la Participación del Cliente”, Congreso Internacional sobre Innovación y
Desarrollo Tecnológico, IIE Cuernavaca Morelos, 2-4 de Abril 2014.
163
[14] CFE-División Valle de México centro, “Beneficios del proyecto AMI Polanco”, en Reunión regional
Meicali, Mexicali, 2012.
[15] CFE-División centro sur, “Blindaje de la red de Baja Tensión y Medición Centralizada”, en Reunión
regional, Cuernavaca, 2014.
[16]. Ochoa, Cesar; S & C, “Proyecto Red Inteligente basado en inteligencia distribuida en Cozumel”,
Seminario de Redes Inteligentes 2014, Cuernavaca, Morelos, 2013.
[17] Rojo Ruben, “Proyecto piloto eliminación de ilícitos eléctricos”, [publicado 28 de Marzo 2013]
Disponible en: www.protecsaing.com.mx
[18] A. López, “Ponen en Querétaro 600 ‘antidiablitos’ ”, El Reforma, p. 7, 1de Junio 2013.
[19] Sánchez Axel, “Redes eléctricas inteligentes oportunidad de mil 500 mdp”, [publicado 18 de Agosto
2015] Disponible en: http://www.elfinanciero.com.mx/empresas/redes-electricas-inteligentes-
oportunidad-de-mil-500-mdp.html
[20] mimorelia.com, “CFE avanza en instalación de medidores”, [publicado 17 de Enero 2016] Disponible
en: http://clasificado.mimorelia.com/noticias/mexico/cfe-avanza-en-instalacion-de-medidores/190592
[21] King-Shan Lui, “Practical and secure Machine-to-Machine data collection protocol in Smart Grid”,
Communications and Network Security (CNS), 2014 IEEE Conference, San Francisco CA. 29-31 Oct.
2014.
[22] Mikel Armendariz, Moustafa Chenine, Lars Nordström, “A Co-Simulation Platform for Medium/Low
Voltage Monitoring and Control applications”, IEEE Conference on Innovative Smart Grid
Technologies (ISGT2014 North America). 2014.
[23] Gianpiero Costantino, Fabio Martinelli, “Privacy-Preserving Energy-Reading for Smart Meter”,
Inclusive Smart Cities and e-Health Volume 9102 of the series Lecture Notes in Computer Science pp
165-177. 30 May 2015.
[24] Organisation Internationale de Métrologie Légale (OIML). “OIML R 46-1/-2”. Francia (Paris):
Organisation Internationale de Métrologie Légale (OIML); 2012.
[25] International Electrotechnical Commission (IEC). “International Standard 62052-11. Electricity

metering equiment (AC)- General requirements, tests and test conditions”. Switzerland (Geneva):
International Electrotechnical Commission (IEC); 2003.
[26] Comisión Federal de Electricidad (CFE). “Sistema de infraestructura avanzada de medición (AMI).
Especificación CFE G0100-05”. México: Comisión Federal de Electricidad (CFE); 2015.
[27] Sebastián C. David J., “Development of a smart metering unit designed to identify energy theft on
distribution networks”, Instituto Politécnico Nacional, Escuela Superior de Ingeniería Mecánica y
Eléctrica, Sección de Estudios de Posgrado e Investigación, Tesis, Enero 2015.
[28] Weisstein, Eric W., “Sampling Theorem”. [On-line]. Disponible en:

http://mathworld.wolfram.com/SamplingTheorem.html
164
[29] Smith, Steven. The Scientist and Engineer´s Guide to Digital Signal Processing. 2nd ed. San Diego,
California: California Technical Publishing, 1999. Impreso.
[30] Slosarcik, Ludek. “FFT-Based Algorithm for Metering Applications”. Freescale Semiconductors
Applications Note AN4255. Rev. 0 (2011): 1-93. Web. 23 Mar. 2012.
[31] Fink, Donald, and Wayne, Beaty. “Manual de ingeniería eléctrica” 3ª ed. McGraw-Hill, 1966. Impreso.
[32] Mladen Kezunovic, “Smart Grids and Beyond: Achieving the Full Potential of Electricity Systems”,
Proceedings of the IEEE, Vol. 100, May 13th, 2012
[33] Zeljko Popovic, “Advanced Metering Infrastructure in the context of Smart Grids”, ENERGYCON
2014, May 13-16, 2014, Dubrovnik, Croatia
[34] I S Jha, “Advanced Metering Infrastructure Analytics-A Case Study”, 978-1-4799-5141-3/14, 2014
IEEE
[35] Steven E Collier, “The Emerging Enernet: Convergence of the Smart Grid with the Internet of Things”,
IEEE Rural Electric Power Conference, 2015
[36] Zacker C, “Redes (Manual de referencia)”. 1ª ed. España: McGrawHill; 2002.
[37] International Business Machines (IBM) Corporation. “IBM HTTP Server (powered by Apache)”. EUA:
IBM Corporation; 2005. Disponible en: https://www.redbooks.ibm.com
[38] Linux FTP Server Setup. (The vsftpd.conf File) [On-line] Disponible en:
https://www.pearsonhighered.com/samplechapter/0131861506.pdf
[39] Ricardo C. “Bases de datos”, 1ª ed, México (D.F.): McGrawHill;2009.
[40] Zikopoulos P, Eaton C., Deroos D. “Understanding Big Data”, 1ª ed. United States of America:
McGrawHills; 2012.
[41] lammertbies.nl, “On-line CRC calculation and free library”. [On-line]. Disponible en:
http://www.lammertbies.nl/comm/info/crc-calculation.html
[42] Maxim Integrated, “Guidelines for Proper Wiring of an RS-485 (TIA/EIA-485-A) Network”. (APP
763) Nov. 2001. [On-line]. Disponible en: https://www.maximintegrated.com/en/app-
notes/index.mvp/id/763
[43] LoRa Alliance, “What is LoRa”, [On-line]. Disponible en: https://www.lora-alliance.org/What-Is-

LoRa/Technology
[44] modbus.org, “MODBUS over Serial Line Specification and Implementation Guide V1.02”. Dec 2006.
[On-line]. Disponible en: http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf
[45] modbus.org, “MODBUS APPLICATION PROTOCOL SPECIFICATION V1.1b3”. [On-line].

Disponible en: http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf
[46] International Business Machines (IBM) Corporation. “TCP/IP Tutorial and technical overview”. EUA:
IBM Corporation; 2005. Disponible en: https://www.redbooks.ibm.com
165
[47] raspberripi.org, “RASPBERRY PI 2 MODEL B”. February 2015. [On-line]. Disponible en:
https://www.raspberrypi.org/products/raspberry-pi-2-model-b/
[48] nxp.com, “FRDM-K64F: Freedom Development Platform for Kinetis K64, K63, and K24 MCUs”.
[On-line]. Disponible en: http://www.nxp.com/products/software-and-tools/hardware-development-
tools/freedom-development-boards/freedom-development-platform-for-kinetis-k64-k63-and-k24-
mcus:FRDM-K64F
[49] appconwireless.com, “Lora Module embedded RF1276T”. [On-line]. Disponible en:

http://www.appconwireless.com/ProShow.asp?id=336
[50] Maxim Integrated, “DS3231 Extremely Accurate I²C-Integrated RTC/TCXO/Crystal”. [On-line].

Disponible en:
https://www.maximintegrated.com/en/products/digital/real-time-clocks/DS3231.html/tb_tab0
[51] huawei.com, “ONT EchoLife HG8110F/HG8120F/HG8240F/HG8245A Productos de la serie de ONT

EchoLife”. [On-line]. Disponible en:
http://e.huawei.com/mx/products/fixed-network/access/ont/optical-terminal
[52] Coaxconnect.com “Lighthorse Technologies Inc.”. [On-line]. Disponible en:

http://www.coaxconnector.com/rp-sma-coax-connectors.php
[53] nxp.com, “CodeWarrior Development Suite”. [On-line]. Disponible en:

http://www.nxp.com/products/software-and-tools/software-development-tools/codewarrior-
development-tools/codewarrior-development-suites/codewarrior-development-suite-special:CW-
SUITE-SPECIAL
[54] raspberry.org, “RASPI-CONFIG”. [On-line]. Disponible en:

https://www.raspberrypi.org/documentation/configuration/raspi-config.md
[55] raspberry.org, “VNC (VIRTUAL NETWORK COMPUTING)”. [On-line]. Disponible en:

https://www.raspberrypi.org/documentation/remote-access/vnc/README.md
[56] i2c-bus.org, “I2C-Bus: What’s that?”. [On-line]. Disponible en: http://www.i2c-bus.org/
[57] raspberrypi-spy.co.uk, “Enabling The I2C Interface On The Raspberry Pi”. November 2014 [On-line].
Disponible en:
http://www.raspberrypi-spy.co.uk/2014/11/enabling-the-i2c-interface-on-the-raspberry-pi/#
166
Concentrador de medidores digitales para sistema de mediciones remotas Apéndice A
Apéndice A: Sistemas de
comunicación y protocolos utilizados
A.1 Redes RS485
La interfaz RS485 ha sido desarrollada para la transmisión en serie de datos de alta velocidad a
grandes distancias (10 Mbit/s en 12 metros, 100 kbit/s en 1200 metros) con creciente aplicación en
el sector industrial. Está concebida como sistema Bus bidireccional con hasta 254 dispositivos.
Puede instalarse en sistemas de 2 hilos como en el caso de este trabajo, pero también hay un modo
de 4 hilos. Dado que varios transmisores trabajan en una línea común, tiene que garantizarse con
un protocolo, en esta caso es MODBUS (ver detalles en Apéndice A.3) que en todo momento esté
activo solo un transmisor de datos. Los otros transmisores tienen que encontrarse en ese momento
en estado de alta impedancia.
La norma RS485 define solamente las especificaciones eléctricas para receptores y transmisores
de diferencia en sistemas de bus digitales. La norma ISO 8482 estandariza además adicionalmente
la topología de cableado con una longitud máx. de 500 metros [42].
El Bus de 2 hilos RS485 se compone según el diagrama de la figura 4.10 de un cable doble
(sugerible par trenzado forrado con una malla llevada a tierra), con una longitud máx. de 500m.
Los dispositivos se conectan a este cable a través de una línea adaptadora de máx. 5 metros de
largo. La ventaja de la técnica de 2 hilos reside esencialmente en la capacidad multi maestro, en
donde cualquier participante puede cambiar datos en principio con cualquier otro. El Bus de 2 hilos
es sólo apto para el modo semidúplex. Es decir puesto que sólo se dispone de una vía de
transmisión, siempre puede enviar datos un solo dispositivo. Sólo después de finalizar el envío,
puede entonces responder algún otro dispositivo.
Figura A.1. Diagrama de una red RS485 a dos hilos
167
Método físico de transmisión: Los datos en serie, como en RS485, se transmiten sin relación a
tierra como diferencia de tensión entre dos líneas correspondientes. Para cada señal a transmitir
existe un par de conductores que se compone de una línea de señales invertida y otra no invertida.
La línea invertida se identifica con la letra "A" o "-", mientras que la línea no invertida con la "B"
o "+". El receptor evalúa solamente la diferencia existente entre ambas líneas, de modo que las
modalidades comunes de perturbación en la línea de transmisión no falsifican la señal útil. Los
transmisores RS485 trabajarán con un nivel de salida de ±2V entre A y B; mientras que los módulos
de recepción reconocen un nivel desde ±200mV como señal válida. Los valores de voltaje
diferencial necesarios para definir a un “1” o “0” lógico son los siguientes:
A-B < -0,3V = “1” A-B > +0,3V = “0”
Longitud de líneas: Usando un método de transmisión simétrico en combinación con cables de

pares de baja capacidad y amortiguación (par trenzado) pueden realizarse conexiones muy eficaces
a través de una distancia de hasta 500m y altas velocidades de transmisión. El uso de un cable TP
de alta calidad evita por un lado la diafonía entre las señales transmitidas y por el otro reduce
adicionalmente al efecto del apantallamiento, la sensibilidad de la instalación de transmisión ayuda
contra las señales perturbadoras entremezcladas.
La terminación de los componentes, cuando se utiliza tiene un gran efecto sobre la corriente en el
enlace. Muchos enlaces con RS-485 tienen una resistencia de 120 ohms a través de las líneas A y
B en cada extremo de la línea como muestra la figura A.1.
A.2 Redes LoRa

LoRaWAN es una especificación de Red de Área Amplia de Baja Potencia ó LPWAN (Low Power
Wide Area Network) por sus siglas en inglés, destinada para la operación de cosas inalámbricas
con muy bajo consumo de potencia, generalmente alimentadas por baterías y que estarán trabajando
dentro de redes regionales, nacionales o globales [43]. LoRaWAN cumple los requerimientos clave
para el Internet de las Cosas tales como:
 servicios de comunicación bidireccional,

 movilidad,
 localización segura.
Esta norma proporcionará interoperabilidad entre objetos inteligentes sin necesidad de

instalaciones locales complejas y da libertad a los usuarios, desarrolladores y empresas para que
permitan el funcionamiento del Internet de las Cosas.
La arquitectura de LoRaWAN presenta una topología de red estrella de estrellas (figura A.2) en la
cual un Gateway (puerta de enlace) actúa como un puente transparente recibiendo y
168
retransmitiendo mensajes entre los dispositivos finales y un servidor de red central que conecta con
en el “back-end” (administrador de la red). Los Gateways están conectados al servidor de red a
través de conexiones IP estándar, mientras que los dispositivos finales utilizan comunicación
inalámbrica “single-hop” (es decir que los datos pasarán directamente de un dispositivo a un
Gateway sin puntos intermedios) a uno o varios gateways. Toda la comunicación al punto final es
generalmente bi-direccional, aunque también soporta “braodcast” (a todos los dispositivos finales
de manera simultánea) permitiendo así actualizaciones de software remotas u otros mensajes de
distribución en masa para reducir el tiempo de comunicación.
Figura A.2. Topología de red LoRa
La comunicación entre los dispositivos finales y Gateways se extiende en diferentes canales de

frecuencia y velocidades de datos. La selección de la velocidad de datos estará en función del
alcance de la comunicación y de la duración del mensaje. Debido a la tecnología de espectro
amplio, las comunicaciones con diferentes velocidades de datos no interfieren entre sí y al crear un
conjunto de canales de "virtuales" se aumenta la capacidad del Gateway. Las velocidades de datos
en una LoRaWAN van desde 0,3 kbps hasta 50 kbps. Para maximizar tanto la vida de la batería de
los dispositivos finales como la capacidad general de la red, el servidor de red LoRaWAN estará
gestionando la velocidad de datos y la salida de RF de manera individual para cada dispositivo
final mediante un esquema de velocidad de datos adaptativa ó ADR (Adaptive Data Rate) por sus
siglas en inglés.
Grandes redes dirigidas a internet de las cosas tales como la infraestructura crítica (energía, gas,
combustibles, agua, telecomunicaciones, transporte, salud, etc.), datos personales confidenciales o
funciones críticas para la sociedad necesitan de una comunicación segura. Esto ha sido resuelto
mediante varias capas de cifrado:
 Clave de red única (EUI64) que garantiza la seguridad a nivel de red.
169
 Clave de aplicación única (EUI64) que garantiza la seguridad end-to-end (extremo a

extremo) a nivel de aplicación.
 Clave específica del dispositivo (EUI128)
Debido a la amplia gama de aplicaciones existentes LoRa tiene tres diferentes tipos de dispositivos
end-point (punto final):
1. Dispositivos finales bidireccionales (Clase A): estos permiten la comunicación

bidireccional mediante la cual la transmisión “uplink” (de enlace ascendente) de cada
dispositivo final es seguida por dos breves ventanas de recepción “downlink” (de enlace
descendente). La ranura de transmisión programada (Receive Slot Scheduled) por el
dispositivo terminal depende de sus propias necesidades de comunicación con una pequeña
variación basada en una base de tiempo aleatorio (protocolo ALOHA). Los dispositivos de
clase A son los dispositivos finales de más baja potencia, recomendados para aplicaciones
que sólo requieren de comunicación de enlace descendente desde el servidor, poco después
de que el dispositivo final haya enviado una transmisión de enlace ascendente.
Comunicaciones de enlace descendente desde el servidor en cualquier otro momento
tendrán que esperar hasta el siguiente enlace ascendente programado.
2. Dispositivos finales bidireccionales con ranuras de recepción programadas (Clase B):

Además de la ventana de recepción aleatoria de clase A, los dispositivos de Clase B abren
ventanas de recepción adicionales durante tiempos programados. Para que el dispositivo
final abra su ventana de recepción a la hora programada este recibe una baliza en un tiempo
sincronizado desde el Gateway. Esto le permite al servidor saber cuándo el dispositivo final
está escuchando.
3. Dispositivos finales bidireccionales con máximas ranuras de recepción (Clase C): Estos
dispositivos tienen ventanas de recepción abiertas casi continuamente, sólo se cierran
cuando están transmitiendo.
A.3 Protocolo de red MODBUS
El MODBUS es un protocolo de comunicación serial basado en el modelo maestro/esclavo, a la

fecha es un estándar, es público, muy seguro, no requiere licencias y su implementación es
relativamente fácil en dispositivos electrónicos. El protocolo MODBUS es un protocolo que usa
líneas seriales, por lo que comúnmente se implementa sobre redes de comunicación RS-485, pero
también sobre redes que usan la comunicación serial RS-232, incluso se puede implementar vía
TCP/IP sobre una red Ethernet.
170
Modos de transmisión MODBUS: estos definen como se envían los paquetes de datos entre
maestros y esclavos, el protocolo MODBUS define dos principales modos de transmisión:
 MODBUS RTU (Remote Terminl Unit). La comunicación entre dispositivos se realiza por
medio de datos binarios. Esta es la opción más usada del protocolo y es la que se
implemento en este trabajo de tesis.
 MODBUS ASCII (American Standard Code for Information Interchange). La
comunicación entre dispositivos se hace por medio de caracteres ASCII.
Funcionamiento del protocolo MODBUS: siempre funciona con un maestro y uno o más
esclavos, siendo el maestro quién controla en todo momento el inicio de la comunicación con los
esclavos, que según la especificación pueden ser hasta 255 en una misma red. El esclavo por otro
lado se limita a retornar los datos solicitados por el maestro. Cada esclavo debe tener una única
dirección, así el maestro sabe con quién se debe comunicar [44]. Las siguientes consideraciones
deben tomarse en cuenta para un sistema comunicado con MODBUS tipo RTU:
 Cada esclavo tiene su propia dirección, que puede ir desde 1 hasta 255.
 El maestro siempre inicia la comunicación enviando un paquete de información (mensaje)
bien estructurado a todos los esclavos, incluyendo el número del esclavo, la instrucción que
se desea que este ejecute, los datos a transmitir y finalmente un número calculado
denominado CRC (Cyclical Redundancy Checking ó en español comprobación de
redundancia cíclica) para verificar que todos los bytes del mensaje sean correctos (ver
figura A.3).
 El esclavo elegido responde, enviando lo que se le pide por medio también de un mensaje.
 El tiempo mínimo entre un mensaje y otro será de 3.5 bytes, si el mensaje es menor los
dispositivos que se estén comunicando deberán reconocerlo como error de colisión.
Antes de Después de
Dir. esclavo Instrucción Datos CRC
iniciar terminar
≥3.5 bytes 1 Byte 1 byte 0 a 252 bytes 2 bytes ≥3.5 bytes
Figura A.3. Formato de un mensaje MODBUS tipo RTU
CRC MODBUS: es un número de 2 bytes o 16 bits calculado en función de todos los bytes
anteriores de un mensaje MODBUS, incluyendo número de esclavo, instrucción y datos, el
algoritmo consta de una serie de operaciones binarias el cual puede verse con detalles en la sección
4.1.1.7. Cada mensaje MODBUS transmitido llevará anexado al final su CRC debidamente
calculado, el receptor deberá tomar el mensaje y nuevamente calcular su CRC para compararlo con
los dos últimos bytes del mensaje original, debiendo ser exactamente iguales, de lo contrario se
considerará un error MODBUS, es decir algún dato se perdió o modificó. Con este CRC se
garantiza que si hay errores en los mensajes tanto esclavos como maestro vuelvan a transmitir la
información necesaria hasta que esta llegue bien.
171
Instrucciones MODBUS: también llamadas funciones son un número de 8 bits (1 byte)

mediante el cual maestro y esclavos definen la tarea a ejecutar. El protocolo MODBUS tiene tres
tipos de instrucciones:
 Públicas: ya definidas y validadas por la comunidad modbus.org
 definidas por el usuario: estarán libres para los desarrolladores y serán definidas, no
estandarizadas y usadas bajo el riesgo y lineamientos de cada fabricante.
 Reservadas: funciones no disponibles para uso público ya que han sido reservadas
legalmente por ciertas compañías.
Para consultar toda el set de instrucciones públicas ya definidas con las que cuenta el protocolo
MODBUS se recomienda checar la referencia [45]. Para el caso de esta tesis solo se hará uso de
tres instrucciones públicas: 0x03, 0x06 y 0x10; mientras que se definieron 7 funciones especiales:
0x00, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E y 0x0F. Todas se explicadas en las siguientes dos secciones.
A.3.1 Protocolo de comunicaciones MODBUS en el MedidorE

Cuando se pretenda acceder a los datos de algún MedidorE directamente con el CMD se utilizarán
las instrucciones MODBUS. El NodoM es capaz de reconocer cuando el CMD está enviando una
petición MODBUS para algún MedidorE y la extrapolará directamente por la red RS485 para que
llegué al MedidorE esclavo correspondiente.
Las instrucciones del protocolo MODBUS programado en el MedidorE solo permitirán leer o
escribir registros. Entiéndase por registros a un conjunto de espacios en la memoria RAM del
dispositivo esclavo (medidor en este caso) donde se almacenan y actualizan constantemente los
valores de las variables a las que se pretende tener acceso (voltaje, corriente, frecuencia, KWh,
KVArh, etc.). Estos registros pueden verse como un arreglo o vector de n posiciones (bytes), para
esta tesis el MedidorE propuesto tendrá 100 registros. Casi todos los registros podrán ser leídos
por el Maestro, solo pocos tendrán permitido escribir en ellos y algunos podrán tanto ser leídos
como escritos.
Con el protocolo MODBUS es posible manejar hasta 255 dispositivos esclavos, pero en este caso
solo serán como máximo 254 medidores ya que además de omitir el dispositivo 0 usado como
“broadcast” o transmisión para todos los esclavos, también se omitirá el dispositivo 1, ya que en
este sistema el esclavo 1 será reservado para el propio dispositivo NodoM el cual a veces trabajará
como esclavo y otras veces como maestro. Inicialmente los MedidorE estarán programados como
el esclavo 255, por lo que a cada nuevo MedidorE que sea conectado al NodoM se le deberá
modificar su número de esclavo mediante instrucciones MODBUS (se explica cómo al final de la
sección 5.1.4).
172
Las instrucciones MODBUS disponibles para comunicarse con el MedidorE son:

 0x03: leer múltiples registros
 0x06: escribir un registro
 0x10: escribir múltiples registros
En la tabla A.1 se muestra cada uno de los 100 registros, los datos que guardan y las restricciones
que presentan (de lectura, escritura o ambas) así como un ejemplo de cómo almacenan los valores.
Tabla A.1. Registros dentro del medidor para leer y/o escribir usando los comando MODBUS
REGISTROS QUE Ejemplo: Valor a representar
PARÁMETRO OCUPA DENTRO DEL RESTRICCIÓN
MEDIDOR Ejemplo almacenado en los registros
m001XYZ000
{0}{1}{2}{3}{4}{5}
{0x6D}{0x30}{0x30}{0x31}{0x58}{0x59}
Número de Serie {6}{7}{8}{9}{10}{11} Lectura
{0x5A}{0x30}{0x30}{0x30}{0}{0}{0}{0}
{12}{13}{14}{15}
{0}{0}
Número de Lectura y 255
{16} Escritura Directa
Esclavo {0xFF}
Lectura y Off=0 / On=1
Estado {17} Escritura BROAD {0}
118.64 Vca
Voltaje [18][19][20][21] Lectura
{0}{1}{18}{64}
[22][23][24][25] 5.78 A
Corriente Lectura
{0}{0}{5}{78}
60.10 Hz
Frecuencia [26][27] Lectura
{60}{10}
Factor de 82.35 %
[28][29] Lectura
Potencia {82}{35}
Distorsión 18.04 %
[30][31] Lectura
Armónica Total {18}{04}
Tiempo de Lectura y 0 hrs 10 mins
[32][33] Escritura BROAD
loggeo {0}{10}
38656.89 KWh
KWh [34][35][36][37] Lectura
{3}{86}{56}{89}
4100.14 KVArh
KVArh [38][39][40][41] Lectura
{0}{41}{00}{14}
THD 2.26 %
promediada
[42][43] Lectura
sobre tiempo de {2}{26}
muestreo
Registros no
No definidos por
definidos [44]……[82] el momento
multipropósitos
m001XYZ000
Registros de {0x6D}{0x30}{0x30}{0x31}{0x58}{0x59}
[83]……[99] Escritura Directa
verificación {0x5A}{0x30}{0x30}{0x30}
{0}{0}{0}{0}{0}{0}
Además en la tabla A.1 se puede ver la restricción para cada registro, estas se clasifican en tres:
173
Lectura: los primeros 44 registros podrán leerse sin ningún problema o restricción. Del
registro [83] a [99] (registros de verificación) no tienen permitido leerse, ya que estos son
únicamente para escribir un número de serie el cual debe ser exactamente igual al del medidor para
que este pueda seguir funcionando, en caso de que no coincidan el medidor se desconectara.
Escritura Directa: significa que solo se podrá escribir este registro si se hace dicha petición
al medidor dirigiéndose directamente con su número de esclavo, no permite escritura por mensaje
“broadcast”. Por ejemplo solo se podrá escribir en el registro[16] para cambiar el número de
esclavo del medidor haciéndole la petición directamente con su número de esclavo actual.
Escritura BROAD: significa que se podrá escribir dirigiéndose por su número de esclavo
o mediante un mensaje BROADCAST, es decir que todos los esclavos de la red podrán modificar
dicho registro simultáneamente haciendo una petición al esclavo 0. Por ejemplo se podrá escribir
en el registro[17] para activar o desactivar a todos los medidores conectados mediante un único
mensaje BROADCAST.
A.3.2 Instrucciones CMD-NodoM

Estas solo funcionaran entre el CMD (quien es el maestro MODBUS y/o Módulo Central LoRa) y
los NodoM (quienes son los esclavos MODBUS y/o Módulos Nodo LoRa), estas instrucciones
servirán para saber la cantidad de medidores, su posición (número de esclavo que tienen), Números
de Serie, así como agregar o eliminar medidores. Las siete instrucciones especiales son:
 0x00: reprogramar radio LoRa

 0x0A: explorar lista_verificacion
 0x0B: verificar medidor por número de esclavo
 0x0C: dar de alta medidor
 0x0D: dar de baja medidor
 0x0E: verificar medidor por número de serie
 0x0F: resetear lista_verificacion
La dirección 1 (0x01) es exclusiva para el NodoM el cual es el único esclavo que reconocerá estas
siete instrucciones. Puede verse con detalle tanto la definición como el uso de cada una en las
secciones 4.2.2.11 a 4.2.2.17
El NodoM trabaja con una matriz o tabla llamada lista_verificacion (ver tabla A.2) la cual está
inicialmente en la memoria RAM de la FRDM-K64F monitoreándose y actualizándose
constantemente, para posteriormente ser guardada en la memoria no volátil (memoria FLASH), en
174
esta matriz se almacenan todos los números de Serie de los medidores que han sido dados de alta
en un mismo NodoM. Se muestra la a continuación la lista_verificacion:
Tabla A.2. lista_verificacion, que almacena los números de serie de los medidores agregados en el NodoM
Números de Serie Libres y disponibles
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Restringido 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
NodoM 1 xx xx xx xx xx xx xx xx xx xx 00 00 00 00 00 00
Medidores
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
Los detalles de la tabla lista_verificacion pueden ser explicados por los puntos siguientes:
 Las 256 filas de la matrix_nodoM representarán a las 256 direcciones esclavos para el
protocolo MODBUS, por lo que el número de fila será equivalente al número de esclavo
MODBUS.
 La fila 0 es una localidad restringida en la cual no se pueden almacenar datos, recordar que
el protocolo MODBUS utiliza la dirección 0 (0x00) como dirección para mensajes
“broadcast”.
 La fila 1 está también restringida para alojar únicamente el Número de Serie del dispositivo
NodoM.
 De las filas 2 a 255 se podrán guardar todos los números de series de los medidores que se
deseen agregar, por lo que solo se podrán agregar máximo 254 medidores.
 Los números de serie de los medidores para CFE constan de tan solo 6 dígitos
alfanuméricos, para esta tesis se están considerando 10, por lo que de la columna 0 a la 9
se almacenaran los dígitos de los números de serie.
 De la columna 10 a la 15 se dejan libres y disponibles para algún dato adicional que se
pretenda almacenar posteriormente para cada medidor, como por ejemplos alarmas.
Como se explica en la sección 4.2 el NodoM se encargará de enviar un mensaje de activación cada
cierto tiempo solo a los medidores que tenga asignados en su lista_verificacion. Un MedidorE
podrá estar conectado al NodoM pero si este no fue correctamente dado de alta no recibirá la señal
de activación necesaria y terminará por desconectarse automáticamente, he aquí la importancia de
esta matriz y del set de instrucciones CMD-NodoM con las que podrá manipularse la información
de esta matriz.
175
A.4 Protocolo TCP/IP

El nombre TCP/IP proviene de dos de los protocolos más importantes de la familia de protocolos
de Internet, el Transmission Control Protocol (TCP) y el Internet Protocol (IP). Dicho protocolo
mantiene en funcionamiento a los exploradores Web, el correo electrónico, chats, nubes de
almacenamiento, entre muchos otros servicios utilizados por millones de personas diariamente,
transfiriendo datos en Internet además de en muchas redes de área local [46].
Un protocolo es un conjunto de reglas a las que se tiene que atener todas las compañías y productos
de software con él fin de que todos sus productos sean compatibles entre ellos. Estas reglas
aseguran que una máquina que ejecuta la versión TCP/IP del sistema operativo WINDOWS pueda
hablar con un teléfono móvil que ejecuta TCP/IP pero en el sistema operativo ANDROID.
TCP/IP es un protocolo abierto, lo que significa que se publican todos los aspectos concretos del
protocolo y cualquiera los puede implementar. TCP/IP está diseñado para ser un componente de
una red, principalmente la parte del software. Todas las partes del protocolo de la familia TCP/IP
tienen unas tareas asignadas como enviar correo electrónico, proporcionar un servicio de acceso
remoto, transferir ficheros, asignar rutas a los mensajes o gestionar caídas de la red.
Una red TCP/IP transfiere datos mediante el ensamblaje de bloques de datos en paquetes. Cada
paquete comienza con una cabecera que contiene información de control, tal como la dirección del
destino, seguida de los datos. Cuando se envía un archivo a través de una red TCP/IP, su contenido
se envía utilizando una serie de paquetes y caminos iguales o diferentes, todos partiendo de un
equipo origen y tratando de llegar a un equipo destino, estas direcciones de origen y destino de
datos se conocen como direcciones IP.
Arquitectura de niveles de TCP/IP: TCP/IP trabaja con cinco niveles de información y datos
(aplicación, transporte, internet, interface de red, físico). Cada nivel añade un bloque de datos al
principio y al final del mensaje que indica que nivel está implicado, además del resto de
información que los otros niveles y la máquina que lo va a recibir necesitan para manejar el mensaje
de forma adecuada. Los datos dentro del mensaje se ignoran. Esto se denomina encapsulación, ya
que cada nivel añade una cápsula de información en torno a los datos originales. Cada nivel lleva
a cabo su propia encapsulación añadiendo cabecera y bloques finales que reciben del nivel superior,
lo que tiene como resultado seis conjuntos de cabeceras y bloques finales en el momento en que
un mensaje llega a la red. Todas estas cabeceras y bloques finales se pasan a la red (como por
ejemplo Ethernet o Netware) que puede añadir incluso más información al principio o al final.
Conjunto de Protocolos TCP/IP: existen una gran cantidad de subprotocolos con diferentes
funciones y servicios para hacer funcionar a TCP/IP. Todos estos servicios crean un protocolo
176
potente y eficaz de red. Los diferentes protocolos dentro de TCP/IP se mantienen de forma regular
por un conjunto de estándares que son parte de la organización de Internet.
Los protocolos de transporte controlan el movimiento de datos entre dos máquinas.
 TCP (Transmission Control Protocol). Protocolo de Control de Transmisión. Un servicio

basado en una conexión, lo que significa que las máquinas que envían y reciben datos están
conectadas y se comunican entre ellas en todo momento.
 UDP (User Datagram Protocol). Protocolo de Datagramas a nivel de Usuario. Un servicio
sin conexión, lo que significa que los datos se envían o reciben estén en contacto entre ellas.
Los protocolos de rutas gestionan el direccionamiento de los datos y determinan el mejor medio de
llegar al destino. También pueden gestionar la forma en que se dividen los mensajes extensos y se
vuelven a unir en el destino.
 IP (Internet Protocol). Protocolo de Internet. Gestiona la transmisión actual de datos.

 ICMP (Internet Control Message Protocol). Protocolo de Control de Mensajes de Internet.
Gestiona los mensajes de estado para IP, como errores o cambios en el hardware de red que
afecten a las rutas.
 RIP (Routing Information Protocol). Protocolo de Información de Rutas. Uno de los varios
protocolos que determinan el mejor método de ruta para entregar un mensaje.
 OSPF (Open Shortest Path First). Abre Primero el Path Mas Corto. Un protocolo
alternativo para determinar la ruta.
Las direcciones de red las gestionan servicios y es el medio por el que se identifican las maquinas,
tanto por su nombre y número único.
 ARP (Address Resolution Protocol). Protocolo de Resolución de Direcciones. Determina

las direcciones numéricas únicas de las máquinas en la red.
 DNS (Domain Name System). Sistema de Nombres de Dominio. Determina las direcciones
numéricas desde los nombres de máquinas.
 RARP (Reverse Address Resolution Protocol). Protocolo de Resolución Inversa de
Direcciones. Determina las direcciones de las máquinas en la red, pero en sentido inverso al
de ARP.
Los servicios de usuario son las aplicaciones que un usuario (o maquina) pueden utilizar.
 BOOTP (Boot Protocol). Protocolo de Arranque, como su propio nombre lo indica,

inicializa una máquina de red al leer la información de arranque de un servidor.
 FTP (File Transfer Protocol), el Protocolo de Transferencia de Ficheros transfiere ficheros
de una máquina a otra.
177
 TELNET permite accesos remotos, lo que significa que un usuario en una máquina puede
conectarse a otra y comportarse como si estuviera sentado delante del teclado de la máquina
remota.
Los protocolos de pasarela ayudan a que la red comunique información de ruta y estado además de
gestionar datos para redes locales.
 EGP (Exterior Gateway Protocol). Protocolo de Pasarela Externo, transfiere información

de ruta para redes externas.
 GGP (Gateway-to-Gateway Protocol). Protocolo de Pasarela a pasarela, transfiere
información de ruta entre pasarelas.
 IGP (Interior Gateway Protocol). Protocolo de Pasarela Interno, transfiere información de
ruta para redes internas.
Existen otros protocolos con servicios que no se adaptan a las categorías, pero proporcionan
servicios importantes en una red.
 NFS (Network File System). Sistema de Ficheros de Red, permite que los directorios en una
máquina se monten en otra y que un usuario puede acceder a ellos como si estos se
encontraran en la máquina local.
 NIS (Network Information Service). Servicio de Información de Red, mantiene las cuentas
de usuario en todas las redes, simplificando el mantenimiento de los logins y passwords.
 RPC (Remote Procedure Call). Llamada de Procedimiento Remota, permite que
aplicaciones remotas se comuniquen entre ellas de una manera sencilla y eficaz.
 SMTP (Simple Mail Transfer Protocol). Protocolo Simple de Transferencia de Correo, es
un protocolo dedicado que transfiere correo electrónico entre máquinas.
 SNMP (Simple Network Management Protocol). Protocol Simple de Gestión de Redes, es
un servicio del administrador que envía mensajes de estado sobre la red y los dispositivos
unidos a ésta.
 HTTP (HyperText Transfer Protocol), Protocolo de Transferencia de HiperTexto, que es
popular porque se utiliza para acceder a las páginas web.
En resumen el TCP/IP es una familia de protocolos a nivel de software necesarios hoy en día para
hacer funcionar las redes de computadora, casi cualquier dispositivo que permita accesos remotos
y conexión a Internet utilizara la familia TCP/IP, por lo que es un hecho ver que los equipos actuales
de medición y manejo de datos en las AMI y en las Redes Eléctricas Inteligentes en general estén
involucrados con uno o varios términos mencionados en este anexo.
178
Concentrador de medidores digitales para sistema de mediciones remotas Apéndice B
Apéndice B: Componentes de Hardware

En la siguiente sección se describen ligeramente los componentes de hardware que componen a
todos los dispositivos propuestos en esta AMI.
B.1 Raspberry Pi 2 modelo B

Es la plataforma que se eligió para formar al CMD, debido a sus características y su capacidad de
funcionar con sistemas operativos libres, prácticamente la convierten en una computadora personal
pequeña, accesible, de muy bajo costo y con un gran soporte en línea por lo que es ideal como
dispositivo educativo para plataformas que requieren sistemas conectados a internet o redes
informáticas [47]. Sus especificaciones son las siguientes:
 CPU: ARM Cortex-A7 de cuatro núcleos a 900MHz

 GPU: núcleo de gráficos 3D VideoCore IV
 RAM: 1 GB LPDDR2 SDRAM 450 MHz
 Puertos: 4 USB, Full HDMI, Ethernet 10/100 Mbps, Conector de audio de 3,5 mm
combinado y vídeo compuesto, Interfaz de cámara (CSI), Interfaz de pantalla (DSI),
Ranura para tarjetas micro SD
 Pines GPIO: 40 de los cuales se cuentan con UART, I2C, SPI, 5Vcc, 3.3Vcc, etc.
 Sistema Operativo: Puede ejecutar toda la gama de distribuciones ARM GNU / Linux,
incluyendo Snappy Ubuntu Core, así como Microsoft Windows 10, de fábrica se obtuvo
con Raspbian.
 Consumo: 5v, 900mA más el de los periféricos (90mA RF1276T y 200μA RTC)
 Dimensiones: 85,60x56,5 mm
 Peso: 45 g
En la figura B.2 se muestra la vista general de la Raspberry Pi2 mientras que en la B.1 se detallan
sus 40 terminales GPIO.
Figura B.1. Detalle de los puertos GPIO de la Raspberry Pi 2
179
Figura B.2. Vista general de la Raspberry Pi 2 modelo B y sus puertos
B.2 FRDM-K64F
La tarjeta de desarrollo FRD-K64F de NXP (anteriormente Freescale) consta de una placa con un
microcontrolador K64F de base y todos los periféricos necesarios para poder utilizarlo en el
desarrollo de proyectos. Para este trabajo de tesis fue la plataforma elegida para implementar el
Medidor y el NodoM, ya que es una plataforma muy completa, con especificaciones muy por
encima de las requeridas para esta tesis, económica y con múltiples puertos de entrada-salida
incluidas terminales de salida de voltaje (5Vcc, 3.3Vcc y GND) gracias a los cuales se pueden
conectar de manera sencilla periféricos adicionales [48]. Sus principales características son:
 CPU: Kinetis K64 (MK64FN1M0VLL12) ARM® Cortex™-M4 con unidad de punto

flotante y DSP, NXP Semiconductors, 120MHz, 256KB RAM, 1MB FLASH
 Puertos: SPI (3), I2C (3), I2S, UART (5), USB OTG / Host / Device, USB regulator, PWM,
ADC (2x 16bit with mux), DAC (12bit), GPIO, Comparator, CAN
 Dispositivos adicionales en la placa de la FRDM-K64F:
o FXOS8700CQ – acelerómetro de 3-ejes y magnetómetro
o Chip Ethernet
o 2 push buttons
o LED RGB
o Pines de expansión para módulo Bluetooth
o Pines de expansión para módulo RF24L01
 Dimensiones: 81mm x 53mm
 Alimentación: 5Vcc por micro USB o fuente de 4.5-9Vcc
180
Figura B.3. Detalle de la FRDM-K64F, sus periféricos y sus puertos
B.3 Módulo RF1276T

El RF1276T (figura B.4) es un transceptor de modulación LoRa (Low Range) de bajo costo, ultra-
baja potencia, alto rendimiento, transparente, bidireccional, semi-duplex con funcionamiento a
frecuencias 169/315/433/868/915 Mhz. Se integra con un chip LoRa SX1276 de Semtech de alta
velocidad y RF de alto rendimiento.
El RF1276T tiene interfaz UART RS232/RS485, haciendo fácil de implementar la transmisión de
datos de forma inalámbrica y facilitando la configuración de parámetros como la velocidad de
transmisión, frecuencia, potencia de salida, (air data rate) velocidad de datos al aire, etc. Puede
transmitir datos de manera transparente con un buffer de datos de gran tamaño (se recomiendo
como máximo 256 bytes) y también puede proporcionar más de 200 canales [49]. Su tamaño
compacto hace que sea una opción ideal para aplicaciones de telemetría y transmisión de pocos
datos a largas distancias, por lo cual se eligió para la AMI propuesta. Sus características principales
son:
 Alcance: 5000 metros de distancia para comunicación a 300 bps bajo condiciones ideales
 Frecuencias soportadas: 169MHz, 315MHz, 405MHz - 440MHz, 868MHz o 915MHz
 Espaciamiento de canales: configurable desde 62.5Khz a 500KHz
 Canales: Posibilidad de más de 200
 Potencia de salida: Max100mW (20dBm)
 Sensibilidad de recepción: -148dBm (@ 600bps)
181
 Velocidad de datos al aire: 300 - 19200 bps, configurable

 Búfer de datos de transmisión: hasta 256 bytes
 Velocidad de datos UART: 1200 - 57600bps, configurable
 Paridad en serial COM: 8E1 / 8N1 / 8O1
 Niveles lógicos: UART / TTL
 Voltaje de alimentación: 4.5 - 5.5V (rizado de menos de ± 100 mV)
 Corriente: 90mA (TX), 19.2mA (RX), 22uA (modo despertar), 3.9uA (modo dormido)
 Configuración: mediante software o mensaje de configuración
 RF_Factor: Modulación LoRa con factor de esparcimiento, parámetro propio de LoRa que
indica cuantos bits de transmisión se requieren para formar un bit de datos el cual puede ir
de 128 a 4096.
 Dimensiones: 34.2mm x 18,4 mm x 7,0 mm
GND
Vcc
EN
RXD
TXD
AUX
SET
Figura B.4. Detalle del RF1276T, dimensiones y pines entrada-salida
Tabla B.1. Descripción de los pines del RF1276T

Pin Nombre Descripción
1 GND Tierra
2 VCC Alimentación (4.5-6.5)V
3 EN (entrada) Pin ENEABLE
4 RXD (entrada) Entrada UART TTL
5 TXD (salida) Salida UART TTL
6 AUX (salida) Señal del modo despertar
7 SET reservado
182
B.4 Módulo RS485

Este módulo permite construir una interfaz RS485 a Serial (5 o 3.3 Vcc). Básicamente consta de
un MAX485 en una tarjeta que incluye además los periféricos básicos para su buen funcionamiento
y las terminales para conectarlo a otros dispositivos o tarjetas mediante terminales cableadas,
eliminando así la necesidad de crear un circuito dedicado solo para poder usar dicho chip. El
MAX485 tiene dos amplificadores, el amplificador D es el encargado de convertir las señales TTL
(5 o 3.3 Vcc) (que entran por RI) a voltajes RS485 (salen por A), este tiene una señal de control
DE aunque también se desactivará si hay señales de entrada por la terminal B. El amplificador R
convertirá las señales RS485 entrantes por B a señales TTL salientes por R0, a su vez cuenta con
un pin de control negado RE (ver figura B.5). En la figura B.6 se muestra el módulo RS485 y en
la tabla B.2 sus pines de entradas y salidas. Las especificaciones técnicas del módulo RS485 son:
 Voltaje de Alimentación: 3.3 o 5 Vcc

 Consumo Corriente: 500 uA (máx)
 Chip principal: MAX485, comunicación Half-Duplex
 Velocidad máxima de transmisión: 10 Mbit/s (a 12 metros)
 Longitud máxima de alcance: 1200 metros (a 100 kbit/s)
 Máximo número de dispositivos soportados: 32
Figura B.5. Diagrama interno de un MAX485 así como sus terminales
Vcc B A GND
RO RE DE D1
Figura B.6. Vista general del módulo RS485 y sus terminales así como el circuito esquemático
183
Tabla B.2. Descripción de los pines del Módulo RS485

1 R0 Salida UART TTL
2 RE Habilitar Transmisión
3 DE Habilitar Recepción
4 DI Entrada UART TTL
5 GND Tierra
6 A Línea invertida RS485
7 B Línea no invertida RS485
8 VCC Alimentación (3.3-5)Vcc
B.5 Módulo DS3231

El DS3231es un reloj de tiempo real o RTC (siglas en inglés de Real Time Clock), de bajo costo,
extremadamente preciso ya que tiene un oscilador integrado con compensación de temperatura de
cristal (TCXO). El dispositivo incorpora una entrada de batería y mantiene un cronometraje preciso
cuando se interrumpe la alimentación principal del dispositivo. La integración del resonador de
cristal mejora la precisión a largo plazo del dispositivo, así como reduce la cantidad de piezas
adicionales requeridas. Tiene compensación de temperatura de precisión de referencia de voltaje y
un circuito comparador que controla el estado de VCC para detectar fallos de alimentación, para
proporcionar una salida de reset y para cambiar automáticamente a la alimentación de reserva
cuando sea necesario [50]. Las principales características de DS3231 son:
 Reloj de tiempo real que cuenta segundos, minutos, horas, fecha del mes, mes, día de la
semana, y año, compensación de años bisiestos, válido hasta 2100
 Precisión ± 2 ppm (de 0 °C a + 40 °C), ± 3,5 ppm (de -40 °C a + 85 °C)
 Salida digital del sensor de temperatura con ± 3 °C de precisión
 Registro en memoria para reducir el envejecimiento
 Botón de reinicio con salida activa en “0”
 Dos alarmas de hora del día
 Salida programable de señal onda cuadrada
 Interfaz rápida I2C (de 400 kHz)
 Entrada de batería de respaldo para asegurar la cuenta del tiempo de forma continua
 Baja potencia de operación para alargar el tiempo de vida de la batería
 Operación a 3.3V
 Temperatura de funcionamiento: Comercial (0 a 70 ° C), industrial (-40 a 85 ° C)
El módulo DS3231 ya cuenta con la batería y demás dispositivos para poder conectarse
directamente a la Raspberry Pi, en la figura B.7 se muestran los detalles de este módulo y en la
tabla B.3 las de sus pines.
184
VCC SDA SCL IO4 GND
Figura B.7. Vista general del módulo DS3231 y sus terminales así como el circuito esquemático
Tabla B.3. Descripción de los pines del Módulo DS3231

1 VCC Alimentación (3.3-5)Vcc
2 SDA Línea SDA del puerto i2c
3 SCL Línea SCL del puerto i2c
4 IO4 Sin uso
5 GND Tierra
B.6 Módulo Convertidor de niveles lógicos

Muchas veces se necesitan compartir señales entre dos dispositivos que trabajan a diferentes
voltajes como por ejemplo de esta tesis el módulo RF1276T que funciona a 5Vcc con la FRDM-
K64F la cual trabaja a 3.3Vcc, ambos necesitan comunicarse por medio del puerto serial pero cada
uno trabajará con los niveles lógicos altos (o unos) a su nivel de voltaje de alimentación por lo cual
no pueden ser conectados directamente ya que la FRDM-K64F con niveles de 3.3V en su puerto
serial probablemente sufrirá daños irremediables al recibir señales de 5 volts.
Para poder interconectarlas se requiere de una interfaz para reducir y/o elevar señales entre 5 y 3.3
V, se pudo adquirir en el mercado un módulo que integra 2 interfaces de este tipo (figura B.8 A).
Reducir de 5V a 3.3V se logra con un simple arreglo de resistencias (figura B.8 B) que trabajan
como divisor de voltaje dando en RX0 solo 2/3 partes del voltaje RX1.
También se requiere el proceso inverso de aumentar una señal de 3.3 a 5 V, analizando la figura
B.8 C se puede ver que cuando se tiene un nivel bajo (0Vcc) en la entrada TX1 una resistencia de
10K crea un voltaje de 3.3V que dispara a un transistor MOSFET haciendo que este entre en
conducción ya que se creará una corriente a través de este y de la resistencia conectada a HV, en
ese momento el voltaje en TX0 será lo suficientemente bajo (no es completamente 0 ya que existe
un pequeño voltaje fuente-drenaje en el MOSFET) como para que la entrada digital del dispositivo
185
lo vea como un cero lógico; cuando en TX1 se tienen 3.3V el voltaje en la resistencia fuente-gatillo
será 0 haciendo que el MOSFET se desactive, en ese caso el único voltaje a la salida TX0 es
directamente el que esté en HV (5 Vcc) reconociéndolo claramente como un uno lógico. En la tabla
B.4 se muestran los detalles de sus terminales.
Figura B.8. Convertidor de niveles lógicos físicamente, sus terminales y su circuito
Tabla B.4. Descripción de los pines del Módulo DS3231

Nombre Descripción
HV Alimentación 5 Vcc
LV Alimentación 3.3 Vcc
GND Tierra
TX1 Señal Tx 3.3 Vcc
TX0 Señal Tx de 5 Vcc
RX1 Señal Rx 5 Vcc
RX0 Señal Rx de 3.3 Vcc
B.7 Enrutador o Router

Se trata de un dispositivo utilizado en redes de área local (LAN - Local Area Network), es decir
aquellas redes que cuentan con una interconexión de computadoras relativamente cercanas, por
medio de cables. El Router permite la interconexión de redes LAN y su función es la de guiar y/o
redireccionar los paquetes de datos para que fluyen hacia la red o equipo correcto e ir determinando
que caminos debe seguir para llegar a su destino, básicamente para trabajar bajo la estructura del
protocolo de red TCP/IP y poder llevar a cabo comunicaciones con servidores HTTP, FTP, VNC,
etc. los cuales pueden encontrarse dentro de la misma LAN o fuera de esta para lo cual también un
router debe de servir como punto de acceso o Gateway hacia una red más grande como una WAN
(Wide Area Network) como la de CFE por ejemplo o a la gran red Worl Wide Web (internet). De
las principales características de un router se pueden mencionar a las siguientes:
186
 Permiten la conexión a la LAN desde otras redes, así como de las computadoras que así lo
soliciten, principalmente para realizar conexiones con servidores HTTP o FTP.
 Se puede interconectar con redes WLAN (Wireless Local Area Network), por medio de
dispositivos inalámbricos como Access Point o Routers Wi-Fi (Wireless Fidelity).
 Funciona como Bridge o puente (comportándose como un nodo intermedio) permitiendo la
conexión de banda ancha entre una WAN (Wide Area Network) y una LAN por medio de
cables UTP (mediante el puerto Ethernet) o conección Wi-Fi.
Para este trabajo de tesis el router forma parte ya del sistema administrador y tiene el propósito de
interconectar al CMD con la o las computadoras desde donde se administrará a toda la AMI.
Prácticamente cualquier router comercial LAN o WLAN que cuente con conexiones Ethernet y
trabaje bajo el protocolo TCP/IP. Se usó el router HG8245H marca HUAWEI (mostrado en la figura
B.9) ya que se disponía de este durante el desarrollo de este proyecto [51]. Este router cuenta con
las siguientes características:
 Router utilizado por compañías proveedoras de internet que utiliza como puerto del lado de
la red conexión de fibra óptica FTTH (Fiber To The Home o fibra hasta el hogar).
 Puertos disponibles (del lado del usuario): 2 POTS (para teléfono), 4 FE (Fast Ethernet), 1
USB y Wi-Fi.
 Trabaja bajo la norma IEEE 802.1ag (involucra TCP/IP y sus subprotocolos) e implementa
la detección de vínculos de extremo a extremo (E2E) y el aislamiento de redes.
 Consumo eléctrico: 9 Watts
 Dimensiones: 34 mm x 268 mm x 213 mm
Figura B.9. Router HG8245H marca HUAWEI
B.8 Computadora Personal

Para este trabajo una computadora personal será la interfaz final de toda la AMI, a través de ella el
administrador tendrá acceso a todos los componentes de la AMI así como también a los archivos
de configuración y de datos de mediciones obtenidos.
187
Se tiene una gran gama de posibilidades para esta computadora, solo necesitará cumplir las
siguientes especificaciones:
 Contar con puerto Ethernet y/o Wi-Fi para poder conectarse con el router.
 Contar con un sistema operativo preferentemente reciente para el buen soporte de
aplicaciones y páginas web, se sugiere alguno de los siguientes: Windows (preferentemente
XP o posterior), Linux o MAC OS.
 La computadora y el sistema operativo deberá tener las especificaciones técnicas necesarias
para poder instalarle y hacer funcionar el siguiente software,
o Filezilla
o Exploradores de internet (Opera, Firefox, Google Chroome, etc.) que soporte
preferentemente HTML5
o TightVNC Viewer
o Phyton 2.7
o Editor de texto
o Hoja de cálculo (Excel por ejemplo o algún otro que permita ver tablas y gráficas)
 Adicionalmente una pantalla de grandes dimensiones ayudaría a visualizar mejor sobre todo
cuando se corra el programa TightVNC Viewer para acceso remoto del CMD.
 Periféricos adicionales básicos de hardware: mouse, teclado, puertos USB para acceso a
memorias o sistemas de almacenamiento masivo.
B.9 Fuentes, conexiones y accesorios de los radios

En esta sección se mencionarán los periféricos adicionales usados en cada uno de los dispositivos
de esta AMI, los cuales no se mencionan en las secciones anteriores ya que son básicos y
generalmente se dan por hecho al momento de mostrar algún circuito, diagrama o sistema.
 Fuentes de alimentación 5V, salida USB (figura B.20):

o Fuente 127 Vac - 5Vcc 2A: Utilizada con la Raspberry Pi 2
o Fuente portable 5V 1A: Utilizados con las FRDM-K64F
Figura B.10. Fuentes de alimentación a 5Vcc con salida USB usadas en esta AMI
188
 Conexiones (figura B.21):

o Terminales tipo Header macho soldables: Utilizadas en los algunos módulos
(convertidor de niveles lógicos) para poder conectarse con cables Dupont.
o Cable Jumper para conexionado rápido: (tipo Dupont macho-macho, macho-
hembra, hembra-hembra) utilizados para conectar las tarjetas de desarrollo con los
diferentes módulos.
o Cable USB a micro USB: utilizado como cable de alimentación de energía en la
Raspberry Pi 2 y las FRDM-K64F, en estas últimas también usado para la
programación.
o Cable Ethernet: Utilizado para conectar al router con la Raspberry Pi 2
principalmente.
Figura B.11. Conexiones utilizadas entre los diferentes periféricos y dispositivos de la AMI
 Convertidores USB-Serial TTL con chip PL2303HXD (figura B.22): cuenta con el
conector especial para configurar a los RF1276T (ver Apéndice F). Este dispositivo es un
interfaz para puerto USB que ya cuenta con los controladores necesarios para ser detectado
por una PC y poder funcionar como un puerto serial con niveles lógicos TTL (5Vcc).
Figura B.12. Adaptador USB-UART con el circuito integrado PL2303HXD
 Antenas con conexión SMA (figura B.23): (Sub-Miniature versión A) es un conector

coaxial para RF fabricado como conector en miniatura para la transmisión de señales por
189
cable coaxial o antenas con un mecanismo roscado. Tiene una impedancia de 50 Ohm y es
excelente para la transmisión de señales de hasta 18 Ghz [52]. Para los RF1276T se
utilizaron dos modelos:
o Antena en ángulo baja ganancia: con ganancia de 2dBi su principal ventaja es su
tamaño compacto pero su rango de alcance es limitado.
o Antena en de alta ganancia: con ganancia de 5dBi esta antena tiene un alcance
mucho mayor pero sus dimensiones también se ven aumentadas, cuenta además con
un cable de extensión y una base.
Figura B.13. Antenas con entrada SMA utilizadas con los radios LoRa RF1276T
190
Concentrador de medidores digitales para sistema de mediciones remotas Apéndice C
Apéndice C: Configuraciones y
Código fuente de MedidorE
C.1 Configuración de los componentes del programa MedidorE con

Processor Expert
El software de programación “CodeWarrior” muestra una herramienta muy útil y completa llamada
“Processor Expert” la cual facilita en gran medida la configuración de los componentes del
microcontrolador que se deseen utilizar y también hace más sencilla la implementación de estos
componentes en un programa. Cuando un componente (ADC, temporizador, PWM, comunicación
serial, SPI, etc.) va a ser agregado a un programa, este debe de ser activado por instrucciones
especiales las cuales deben cargarse por medio de las bibliotecas correspondientes con las
subfunciones y rutinas necesarias para que dichos componentes puedan trabajar en nuestros
códigos. Antiguamente el proceso más común para utilizar algún componente del microcontrolador
era primero buscar dicho componente en la hoja de datos, ver los registros necesarios para activarlo,
configurarlo y finalmente poder ocuparlo con instrucciones básicas. Ahora herramientas como
“Processor Expert” nos permiten simplemente buscar los dispositivos de una lista, agregarlos al
proyecto de nuestro programa, seleccionar las configuraciones e interrupciones deseadas (en caso
de que maneje interrupciones) y finalmente compilarlo dejando así que “Processor Expert” haga
todo el trabajo de cargar bibliotecas y activarlas con las configuraciones que se le indicaron, para
finalmente tan solo buscar en una lista la o las instrucciones que necesitaremos ejecutar desde
nuestro programa principal [53].
Los componentes del microcontrolador K64F utilizados y configurados para el programa Medidor
se enlistan a continuación:
 CPU
 Pin ENEABLE para el control del módulo RS485
 Comunicación serial para RS485
 Temporizador con interrupción
 Reloj en tiempo real
 Memoria FLASH para guardar datos
 Pin de salida para LED rojo
191
C.1.1 Configuración del CPU
Las principales modificaciones en el CPU de este proyecto fueron:

 Modificar el procesador ya que por defecto trae el MK64FN1M0VLQ12, y el de nuestra
FRDM-K64F es el MK64FN1M0VLL12 (ver figura C.1).
 Modificar la memoria de trabajo, en la ventana “Components Inspector” puede verse que
por defecto se pone la RAM, así que debe cambiarse por FLASH (ver figura C.2).
Figura C.1. Para seleccionar el microcontrolador adecuado en la ventana “Components Inspector”,

en la casilla “CPU type” buscar y seleccionar al MK64FM0VLL12
Figura C.2. Para seleccionar la memoria de trabajo se da clic izquierdo en FLASH

y se selecciona la opción “Select Configuration as Active”
Para el programa Medidor no se requirió alguna configuración especial del reloj del procesador.
La velocidad máxima sería deseable en un medidor real para obtener más precisión de las
mediciones pero para objeto de esta tesis donde el medidor realiza mediciones inventadas no fue
necesario modificar la velocidad de procesamiento más allá de la que “Processor Expert” da por
defecto (Mcg mode: FEI, Core Clock: 20.97MHz, Bus Clock: 20.97MHz y demás configuraciones
predeterminadas).
192
C.1.2 Pin ENEABLE para el control del módulo RS485
Dicho módulo se basa en el MAX485, el cual es el circuito integrado encargado de enlazar los
niveles de voltaje RS485 con los niveles lógico del microcontrolador K64F (3.3V). Como se
explica en el Apéndice B.4 este chip tiene dos terminales DE y RĒ conectados de manera que
aplicándoles un 0 se pondrá al MAX485 en modo recepción y con un 1 se pondrá en modo
transmisión. Estos pines deben ser controlados por el microcontrolador por medio de un pin de
salida dedicado al que nombró ENEABLE, su configuración se muestra en la tabla C.1.
Tabla C.1. Configuración básica de ENEABLE para controlar el MAX485
-Pin utilizado PTC11

- como salida digital
-Valor inicial 1
C.1.3 Comunicación serial para RS485
Una tarjeta FRDM-K64F estará corriendo el programa Medidor, para que este funcione debe estar
conectado a un NodoM, y el medio de comunicación entre estos dos es una red RS485 operando
bajo el protocolo MODBUS, se tienen como interfaz a un módulo RS485 que conecta a la red
RS485 con el Medidor para lo cual hará uso de un puerto serial al cual por practicidad se le puso
el nombre de RS485. Los parámetros de configuración se muestran en la tabla C.2.
193
Tabla C.2. Configuraciones básicas del puerto serial
-Se usa el puerto UART3

-Interrupción por recepción de datos
-Interrupción por transmisión de datos
-Interrupción por error de datos
-No paridad
-Transmisión de 8 bits
-1 bit de parada
-Terminal PTB10 como Rx
-Terminal PTB10 como Tx

-9600 bauds en velocidad de transmisión
-Comenzar transmisión después de bit de

arranque
-Inicializar automáticamente
C.1.4 Temporizador con interrupción

Debido a que en el componente de comunicación serial llamado RS485 generado por “Processor
Expert” no se cuenta con una función que reciba un número de bytes indefinidos y que active la
interrupción una vez que se termina dicha recepción (sería lo ideal) esta tarea se tiene que hacer
con ayuda de un temporizados adicional que estará contabilizando milisegundos después de cada
dato recibido y reseteándose con el nuevo byte entrante (ver interrupciones en la sección 4.1.3),
este temporizador con interrupción fue definido como TI1 y su configuración se muestra en la tabla
C.3.
Tabla C.3. Configuración básica de ENEABLE para controlar el MAX485
-Fuente de interrupción periódica
-Resolución del temporizador
-No inicializado al inicio, se hará

por programa
194
C.1.5 Reloj en tiempo real
El programa Medidor monitorea continuamente cada nuevo minuto para estar guardando datos en
la memoria FLASH o para estar checando el mensaje de verificación procedente del NodoM (ver
f_checa_medidor en la sección 4.2.1.4), para estas tareas bien se puede usar otro temporizador
similar al TI1, pero se usó un componente que ejecuta un reloj en tiempo real llamado por defecto
TmDt1. Este componente también será de gran utilidad en el caso de que se quiera tener un registro
con fecha y hora para alarmas (ver trabajos futuros sección 6.3). Su configuración se muestra en la
tabla C.4.
Tabla C.4. Configuración básica del temporizador
-Fuente de interrupción periódica
-Resolución de tiempo
- Inicio automático
- Hora de inicio
- Fecha de inicio
C.1.6 Pin de salida para LED rojo
Para poder ver físicamente la simulación del medidor en estado “activado” o “desactivado” se
utilizó el LED rojo el cual forma parte de la FRDM-K64F, este se controla como un pin de salida
digital como se muestra en la tabla C.5.
Tabla C.5. Configuración del LED rojo
-Pin utilizado PTB22

-como salida digital
-Valor inicial de la salida 1
195
C.1.7 Memoria FLASH para guardar datos
Para poder guardar los datos de mediciones sobre todo los acumulativos como KWh y KVArh es
necesario utilizar una memoria no volátil; el K64F cuenta con 1Mb de memoria FLASH en la cual
se destina cierta posición para guardar el programa principal pero se dispone de suficiente espacio
como para guardar otros datos. La documentación de “CodeWarrior” sugiere utilizar a partir de la
dirección 0xF000 en la memoria FLASH del K64F para alojar datos adicionales y no tener
conflictos con el sector de memoria FLASH predefinido para el programa principal. Se muestra en
la tabla C.6 la configuración básica del componente IFsh1 generado por “Processor Expert” para
administrar la memoria FLASH.
Tabla C.6. Configuración de componente de Memoria FLASH
-Escritura en FLASH habilitada

-Interrupción deshabilitada
-El programa esperará hasta que se complete la

escritura o berrado de memoria FLASH
-Habilitado desde el inicio
196
C.2 Código fuente: main.c

#include "Cpu.h"
#include "Events.h"
#include "Pins1.h"
#include "RS485.h"
#include "ASerialLdd1.h"
#include "LED_Rojo.h"
#include "BitIoLdd1.h"
#include "ENEABLE.h"
#include "TU1.h"
#include "TI1.h"
#include "TimerIntLdd1.h"
#include "TmDt1.h"
#include "TimeDateLdd1.h"
#include "TU2.h"
#include "IFsh1.h"
#include "IntFlashLdd1.h"
/* Including shared modules, which are used for whole project */
#include "PE_Types.h"
#include "PE_Error.h"
#include "PE_Const.h"
#include "IO_Map.h"
#include "PDD_Includes.h"
#include "Init_Config.h"
#include <stdlib.h> // LIBRERÍA usada para la funcion rand()
void f_reset(void);
void f_inicia_medidor(void);
void f_medidor(void);
void f_MODBUS(void);
void f_analizar_mensaje(void);
void f_calcular_crc(int,byte);
void f_lee_multi(void);
void f_escribe_uno(void);
void f_escribe_multi(void);
void f_formar_replica(void);
void f_enviar_replica(void);
//------------VARIABLES GLOBALES
byte registro[100]; ////// Registros par leer y escribir en MODBUS
///////////////////////////// Variables usadas para recibir los mensajes por RX
extern int n, // Contador de bytes de mensajes recibidos por Rx de RADIO
timmer; // timmer usado para contar los bytes recibidos
extern byte mensaje_recibido[100]; // Mensaje recibido por el Maestro
///////////////////// Del MENSAJE RECIBIDO tipo MODBUS se obtienen los siguientes datos:
byte num_disp; // Num. del dispositivo esclavo al que se hace referencia
byte instruc; // Num. de Instrucción o Función
byte datos_recibido[96]; // Bytes de datos_recibido
byte crc[2]; // Valores de CRC a 16 bits
//////////////////////////// VARIABLES PARA LAS FUNCIONES DE CRC
byte crc_a, crc_b; // Bytes alto y bajo del CRC calculado
//////////////////// BANDERAS
byte error; // para chechar error,
static int numdatos_check;//
int crc_check=0, numdisp_check=0; // para chechar cr y num. de esclavo,
modbus_check=0; // y si se recibio un mensaje MODBUS
//////////////////// VARIABLES PARA FORMAR MENSAJE DE REPUESTA
byte datos_replica[96], // DATOS que serán transmitidos en el MENSAJE REPLICA
*ap_tx; // Apuntador para usar en Tx de RADIO
extern int longitud; // Tamaño final en bytes del mensaje_replica[]
extern byte mensaje_replica[100]; // Mensaje replica para ser aneviado al Maestro
int d; // Tamaño en bytes de los DATOS a anexar dentro del mensaje_replica[]
////////////////////////////////
byte min_ant=0,cont_mins=0; //
byte dKWh,dKVArh; //
uint16_t KWh,KVArh; //
uint32_t Wh,VArh; // Variables globales para f_medidor()
197
///////////////////////////////
int main(void)
{///////////////////////////////
//*** ********************************************************************
PE_low_level_init();// Inicialización de Processor Expert
//************************************************************************
//
// f_reset(); // Solo usada para pruebas
//
f_inicia_medidor(); // Se cargan los datos de las FLASH a la RAM
//
for(;;) //
{ //
f_medidor(); // El programa se centrará en la función de medicion
} //
//
/**************************************************************************
#ifdef PEX_RTOS_START
PEX_RTOS_START(); // Lineas de Precessor Expert no modificables
#endif
/*************************************************************************
}
void f_reset(void)
{//////////////////////////////////////
int i; //
byte num_serie[]={'m','0','0','1','X','Y','Z','0','0','0',0,0,0,0,0,0};
byte vector_grabar[100]; //
IFsh1_TAddress direccion=0xF000; // Posicion en MEMORIA FLASH
//
for(i=0;i<16;i++) //
vector_grabar[i]=num_serie[i]; // Guarda el Num. Serie del medidor en vector_grabar[0 a 15]
vector_grabar[16]=0xFF; // Guardamos el num. de esclavo como 0xFF
for(i=17;i<100;i++) // Ponemos en ceros vector_grabar[17 a 43]
vector_grabar[i]=0; //
//
IFsh1_EraseSector(direccion); // Se borra sector de Flash(obligatorio antes de escrbir)
IFsh1_SetBlockFlash(&vector_grabar[0],direccion,sizeof(vector_grabar));
}////////////////////////////////////
void f_inicia_medidor(void)
{//////////////////////////////////////
byte i,Dato; //
IFsh1_TAddress direccion=0xF000; // Posicion en MEMORIA FLASH donde se tomaran datos
//
for(i=0;i<100;i++){ //
IFsh1_GetByteFlash(direccion + i, &Dato);// Se leen todos los datos de la memoria Flash
registro[i]=Dato; // y se copian en registro[]
ENEABLE_ClrVal(); // se pone a RS485 en 0 (ESCUCHANDO)
} //
//
KWh=(registro[34]*10000)+(registro[35]*100)+(registro[36]);
KVArh=(registro[38]*10000)+(registro[39]*100)+(registro[40]);
Wh=(KWh*1000)+(registro[37]*10); //
VArh=(KVArh*1000)+(registro[41]*10);
}//////////////////////////////////////
void f_medidor(void)
{//////////////////////////////////////
byte min,i,j; //
byte Volt,Amper,frec,fp,THD,rel_ang;
unsigned int watt,VAr; //
byte dVolt,dAmper,dfrec,dfp,dTHD,dwatt,dVAr;
byte THD_t,dTHD_t; //
TIMEREC time; //
IFsh1_TAddress direccion=0xF000; // Posicion en MEMORIA FLASH
//
Volt=10+(rand()%21); // decenas de Voltaje de 10 a 30
198
dVolt=rand()%100; // decimas de voltaje de 0 a 99

Amper=rand()%31; // decenas de correinte de 0 a 30
dAmper=rand()%100; // decimas de corriente de 0 99
frec=59+(rand()%2); // decenas de frecuencia de 59 a 60
dfrec=rand()%100; // decimas de frecuenci de 0 a 99
fp=99-(rand()%35); // decenas de fp de 64 a 99
dfp=rand()%100; // decimas de fp de 0 a 99
THD=rand()%21; // decenas de THD de 0 a 20
dTHD=rand()%100; // decimas de THD de 0 a 99
//
TmDt1_GetTime(&time); //
min=time.Min; //
if(min_ant!=min){ //
rel_ang=1+(rand()%50); // 100*tan(arccos(fp/100))
dwatt=rand()%100; // solo valores no mayores a 99
dVAr=rand()%100; //
watt=rand()%3001; // solo valores no mayores a 3000
VAr=(watt*rel_ang)/100; // Calculo de VAr
//
Wh=Wh+(watt/60); // se logea la potencia cada 60 minutos
KWh=Wh/1000; // de Wh a KWh
dKWh=(Wh-(KWh*1000))/10; // decimas de KWh
VArh=VArh+(VAr/60); //
KVArh=VArh/1000; // se logea la potencia reactiva cada 60 minutos
dKVArh=(VArh-(KVArh*1000))/10; // de VArh a KVArh
cont_mins++; // decimas de KVArh
} //
//
if(cont_mins==6){ // Cada 3 minutos se checa el código de verificacion
j=0; //
for(i=0;i<10;i++) // Compara Num. Serie del medidor (registro[0] a registro[9])
if(registro[i]==registro[83+i])// con los escritos en los registros de verificación
j++; //(registro[83] a registro[93])
//
if(j==10) // si coinciden
registro[17]=registro[17]; // el ESTADO del medidor (registro[17]) se conserva
else //
registro[17]=0; // pero si no se hara registro[17]=0 (desactivara al medidor)
//
for(i=0;i<10;i++) //
registro[83+i]=0; // Hecho esto se resetean registros de verificacion
cont_mins=0; // esperando que se actualicen nuevamante con el Num. Serie
} // correcto durante los proximos 3 minutos
//
numes_med=registro[16]; // Num. Esclavo asignado
//
if(registro[17]==0) // EDO: Estado off=0/on=1 = {0/1}
LED_Rojo_SetVal(); // si el registro[17] se modifica
else // se enciende o apaga el medidor
LED_Rojo_ClrVal(); //
//
registro[18]=0;registro[19]=1; // V: Voltaje = 118.64V = {0,01,18,64}
registro[20]=Volt;registro[21]=dVolt;
registro[22]=0;registro[23]=0; // I: Corriente = 5.78A = {0,0,5,78}
registro[24]=Amper;registro[25]=dAmper;
registro[26]=frec;registro[27]=dfrec;// f: frecuencia = 60.10Hz = {60,10}
registro[28]=fp;registro[29]=dfp; // fp: factor de potencia = 82.35% = {82,35}
registro[30]=THD;registro[31]=dTHD;// THD: Distorsión Armónica Total = 18.04% = {18,04}
//
//registro[32]=0;registro[33]=10; // t THD: tiempo muestreo para THD = 60.10Hz = {0,10}
registro[34]=KWh/10000; //
registro[35]=(KWh-(registro[34]*10000))/100;// KWh: KiloWatt hora = 3.89KWh = {0,0,3,89}
registro[36]=(KWh-(registro[34]*10000))-(registro[35]*100);
registro[37]=dKWh; //
registro[38]=KVArh/10000; //
registro[39]=(KVArh-(registro[38]*10000))/100;// KVArh: KiloVoltAmper reactivo hora =
0.18KVArh = {0,0,0,18}
registro[40]=(KVArh-(registro[38]*10000))-(registro[39]*100);
registro[41]=dKVArh; //
registro[42]=rand()%21; //
registro[43]=rand()%100; // THD/t: THD promedio/t = 2.26% = {2,26}
199
//
//
if(min_ant!=min){ //
IFsh1_EraseSector(direccion); // Borra sector de Flash(obligatorio antes de escrbir)
IFsh1_SetBlockFlash(&registro[0],direccion,sizeof(registro)); // Se guarda el vector
registro[] en FLASH
min_ant=min; //
} //
//
if(modbus_check==1) // se checa si se recibio un mensaje MODBUS
f_MODBUS(); // si es asi, se ejecuta la funcion MODBUS
}//////////////////////////////////////
void f_MODBUS(void)
{//////////////////////////////////////
TI1_Disable(); // Se desactiva el TI1 usado para detectar fin de recepcion
//
f_analizar_mensaje(); // ejecuta función para analizar mensaje recibido
//
if (numdisp_check==1 && crc_check==1 && num_disp>1 && numdatos_check==1)
{ // 0 y 1 estan restringidos para responder
f_formar_replica(); // ejecuta función para formar el mensaje de replica
//
f_enviar_replica(); // ejecuta función para enviar mensaje de replica
} //
modbus_check=0; //
n=0; // reset para contar de un nuevo mensaje
ENEABLE_ClrVal(); // se vuelve a poner en 0 (RECIBIENDO) al MAX485
}//////////////////////////////////////
void f_analizar_mensaje(void)
{//////////////////////////////////////
int i; //
//
num_disp=mensaje_recibido[0]; //
instruc=mensaje_recibido[1]; //
for(i=0;i<(n-4);i++) // datos_recibido[{0},..,{(n-4)-1}]=mensaje[{2},..,{(n-2)-1}];
datos_recibido[i]=mensaje_recibido[i+2];
for(i=0;i<2;i++) // crc[{0},{1}]=mensaje[{n-2},{n-1}];
crc[i]=mensaje_recibido[(n-2)+i];
//
f_calcular_crc((n-2),&mensaje_recibido[0]); // Se calcula el CRC del mensaje recibido donde
// n-2=long_crc y &mensaje_recibifo[0]=*ap_crc
if (crc[0]==crc_a && crc[1]==crc_b)
{ //
crc_check=1; //
if(num_disp==numes_med || num_disp==0)
{ //
numdisp_check=1; //
error=0; //
if(instruc==0x03 && num_disp>1)
f_lee_multi(); //
else if(instruc==0x06) //
f_escribe_uno(); //
else if(instruc==0x10) //
f_escribe_multi(); //
else //
error=0x01; //
} //
} //
}//////////////////////////////////////
void f_calcular_crc(int long_crc, byte *ap_crc) // ALGORITMO CRC MODBUS 16 bits

{/////////////////////////////////////////////////////
byte i,j; //
uint16_t crcshift,crcsum = 0xFFFF; //
//
for (i = 0; i < long_crc; i++) { //
200
crcsum = (uint16_t)(crcsum^(*(ap_crc+i))&0x00FF);
for(j=0;j<8;j++) { //
crcshift = (uint16_t)((crcsum>>1)&0x7FFF); //
if (crcsum&0x0001) //
crcsum = (uint16_t)(crcshift^0xA001); //
else //
crcsum = crcshift; //
} //
} //
crc_a=(crcsum>>8); // El CRC calculado se guarda
crc_b=crcsum; // en 2 varibles de 8 bits
}/////////////////////////////////////////////////////
void f_lee_multi(void) // INSTRUCCION 0x03 MODBUS

{//////////////////////////////////////
int i,reg_inicio,cantidad_regs; //
//
reg_inicio=datos_recibido[1]; //
cantidad_regs=(datos_recibido[3])*2; // cuantos registros (bytes*2) a leer
//
if(n==8){ // Para esta funcion deben ser recibidos solo 8 bytes,
numdatos_check=1; // solo así se ejecutara la lectura
if(reg_inicio<83 && (reg_inicio+cantidad_regs)<83)
{ //
datos_replica[0]=cantidad_regs;
for(i=0;i<cantidad_regs;i++)//
{datos_replica[1+i]=registro[reg_inicio+i];}
d=cantidad_regs+1; //
} //
else // Del registro 100 en adelante ya no son validos
error=0x02; // por lo que escoger alguno de estos genera el error 2
}else //
numdatos_check=0; // Longitud total del mensaje invalida
}//////////////////////////////////////
void f_escribe_uno(void)// INSTRUCCION 0x06 MODBUS

{//////////////////////////////////////
int i,reg_inicio; //
//
//
if(n==8){ // Para esta funcion deben ser recibidos 8 bytes,
numdatos_check=1; // solo asi se ejecutara la escritura
if(reg_inicio==16 || reg_inicio==17 || reg_inicio==32 || reg_inicio==33){
// Los unicos registros en los que puede escribirse de manera individual son 17, 32 y 33
if(num_disp>1){ //
registro[reg_inicio]=datos_recibido[3];
for(i=0;i<4;i++) //
datos_replica[i]=datos_recibido[i];
d=4;} //
else{ //
if(reg_inicio!=16) //
registro[reg_inicio]=datos_recibido[3];
} //
} //
else //
error=0x22; // Si se escogio algun registro restringido causa el error 22
}else //
//
if(reg_inicio>99) // Del registro 114 en adelante ya no son validos
error=0x02; // por lo que escoger alguno de estos genera el error 2
}////////////////////////////////////
void f_escribe_multi(void)// INSTRUCCION 0x10 MODBUS

{//////////////////////////////////////
int i,reg_inicio,cantidad_regs; //
//
cantidad_regs=datos_recibido[4]; //
201
//
if(n==(9+cantidad_regs)){ // Esta funcion debe recibir (9 + cantidad_regs) bytes,
numdatos_check=1; // solo si coincide con n, se ejecuta la escritura multiple
if(reg_inicio==32 || reg_inicio>=83) // La escritura multiple solo puede hacerse de
{ // los registros [32] a [33] o del [83] al [99]
for(i=0;i<cantidad_regs;i++)//
registro[reg_inicio+i]=datos_recibido[5+i];
//
datos_replica[0]=0; //
datos_replica[1]=reg_inicio;
datos_replica[2]=0; //
datos_replica[3]=datos_recibido[3];
//
d=4; //
}else //
error=0x22; // se genera error 22 Si se escogio un registro restringido
}else //
}//////////////////////////////////////
void f_formar_replica(void)
{//////////////////////////////////////
int i; //
mensaje_replica[0]=num_disp; // Identificador del numero de dispositivo
mensaje_replica[1]=instruc; // Identificador de la instrucción
//
//------------ SI HUBO ERROR 0x01 DE instruccion
if(error==0x01){ //
mensaje_replica[1]=mensaje_replica[1]+0x80;
datos_replica[0]=0x01; //
d=1; //
} //
//------------ SI HUBO ERROR 0x02 DE registro
if(error==0x02){ //
d=1; //
} //
//------------ SI HUBO ERROR 0x22 DE escritura
if(error==0x22){ //
d=1; //
} //
//------------ SI NO HUBO NINGUN ERROR
for(i=0;i<d;i++) //mensaje_replica[{2},..,{(n-2)-1}]=mensaje_error_crc[{0},..,{n-1}];
mensaje_replica[i+2]=datos_replica[i];
longitud=d+4; //
//
f_calcular_crc(longitud-2, & mensaje_replica[0]);// Se calcula el CRC del mensaje_replica
//
mensaje_replica[longitud-2]=crc_a;// Agregando Valor alto del CRC del mensaje_replica
mensaje_replica[longitud-1]=crc_b;// Agregando Valor bajo del CRC del mensaje_replica
//
ap_tx=mensaje_replica; // apuntando a Mensaje a enviar
}//////////////////////////////////////
void f_enviar_replica(void)
{////////////////////////////////////// Función para enviar el mensaje
ENEABLE_SetVal(); // Pone al MAX485 en 1 (TRANSMITIENDO)
RS485_SendChar(*ap_tx); // Envia el dato apuntado por ap_tx por el p. serial RADIO
ENEABLE_ClrVal(); // Regresa al MAX485 en 0 (RECIBIENDO)
}//////////////////////////////////////
202
C.3 Código fuente: Events.c

#include "Cpu.h"
#include "Events.h"
#ifdef __cplusplus
extern "C" {
#endif
int n=0;
byte mensaje_recibido[100];
byte mensaje_replica[100];
int longitud,timmer=5;
extern byte *ap_tx;
extern int modbus_check;
void Cpu_OnNMI(void)
{
// Evento generado pero no usado
}
void RS485_OnError(void)
{
}
void IFsh1_OnWriteEnd(void)
{
}
void RS485_OnRxChar(void)
{
RS485_TComData ch;
if(RS485_RecvChar(&ch) == ERR_OK){ //Lee dato y lo manda si no hay error
mensaje_recibido[n]=ch;
}
TI1_Enable();
timmer=5;
n++;
}
void RS485_OnTxChar(void)
{
ap_tx++;
longitud--;
if(longitud>0){
RS485_SendChar(*ap_tx);
}
}
void TI1_OnInterrupt(void)
{
if(timmer==0)
modbus_check=1;
if(timmer!=0)
timmer--;
}
/* END Events */
#ifdef __cplusplus
} /* extern "C" */
#endif
203
204
Concentrador de medidores digitales para sistema de mediciones remotas Apéndice D
Apéndice D: Configuraciones y
Código fuente de NodoM
D.1 Configuración de los componentes del programa NodoM con

Processor Expert
Los componentes del microcontrolador K64F utilizados y configurados para el programa NodoM
son muy similares a los utilizados en el MedidorE por lo que en esta sección no se profundizará
demás. Los componentes utilizados mediante “Processor Expert” se enlistan a continuación:
 CPU
 Comunicación serial para radio LoRa
 Comunicación serial para RS485
 Pin ENEABLE para el control del MAX485
 Temporizador con interrupción
 Reloj en tiempo real
 Memoria FLASH para guardar datos
D.1.1 Configuración del CPU
Se utilizó exactamente la misma configuración que en el programa Medidor por lo que para ver
más detalles consultar la sección C.1.1 y las figuras C.1 y C.2.
D.1.2 Comunicación serial para radio LoRa
Al igual que con el caso anterior, este componente utilizado como puerto serial para comunicarse
con el radio LoRa tiene exactamente la misma configuración que el puerto serial RS485 del
MedidorE por lo cual se recomienda revisar la sección C.1.3 así como la tabla C.2. La única
diferencia es que en este programa el componente se nombró RADIO.
205
D.1.3 Comunicación serial para RS485
Este puerto llamado RS485 en este programa tiene casi la misma configuración que el anterior
exceptuando el puerto utilizado, los pines de salida y que no se inicializará automáticamente. La
configuración se muestra en la tabla D.1.
Tabla D.1. Configuraciones básicas del puerto serial para el RS485 del NodoM
-Se usa el puerto UART2

-Interrupción por recepción de datos
-Interrupción por transmisión de datos
-Interrupción por error de datos
-No paridad
-Transmisión de 8 bits
-1 bit de parada
-Terminal PTD2 como Rx
-Terminal PTD3 como Tx

-9600 bauds en velocidad de transmisión
-Comenzar transmisión después de bit de

arranque
-Este puerto no se inicializar automáticamente,
se hará posteriormente por programa
D.1.4 Pin de control para el módulo RS485
Este componente llamado controlRS485 es exactamente igual al llamado ENEABLE del

MedidorE. Para más detalles revisar la sección C.1.2 así como la tabla C.1.
D.1.5 Temporizador con interrupción
También llamado TI1 y con la misma configuración que en Medidor (para más detalles revisar la
sección C.1.4 y la tabla C.3). Inicialmente tiene el mismo propósito que en el programa MedidorE
(controlar la comunicación serial) pero en este caso al manejarse dos puertos seriales las subrutinas
que lo implementan serán más complejas como se verá en la sección de eventos más adelante.
206
D.1.6 Reloj en tiempo real
Llamado TmDt1 y con la misma configuración que en MedidorE (ver detalles en la sección C.1.5
y en la tabla C.4) el propósito de este componente en más de una ocasión será el de monitorear
cambios o eventos cada minuto con la finalidad de no tener que agregar temporizadores y rutinas
o eventos adicionales.
D.1.7 Memoria FLASH para guardar datos
Los detalles de configuración se pueden ver en la sección C.1.7 y en la tabla C.6). Este componente
llamado también IFsh1 tiene el propósito de servir como memoria de datos permanentes a
diferencia del programa MedidorE que guarda mediciones en el NodoM almacenará la lista de
verificación de los medidores, guardando específicamente los números de serie en la sección
correspondiente al número de esclavo que se les asignó al darlos de alta.
D.2 Código fuente: main.c

#include "Cpu.h"
#include "Events.h"
#include "Pins1.h"
#include "RADIO.h"
#include "ENEABLE.h"
#include "IFsh1.h"
#include "IntFlashLdd1.h"
#include "LED_rojo.h"
#include "TI1.h"
#include "TimerIntLdd1.h"
#include "TU1.h"
#include "RS485.h"
#include "TmDt1.h"
#include "TimeDateLdd1.h"
#include "TU2.h"
#include "PE_Types.h"
#include "PE_Error.h"
#include "PE_Const.h"
#include "IO_Map.h"
void f_nvoCMD_mensaje(void);
void f_analizar_mensaje(void);
void f_checar_crc(void);
void f_calcular_crc(void);
void f_checar_numdisp(void);
void f_checar_instruc(void);
void f_formar_replica(void);
void f_inicia_nodoM(void);
207
void f_nodo_0x00(void);
void f_nodo_0x0A(void);
void f_nodo_0x0B(void);
void f_nodo_0x0C(void);
void f_nodo_0x0D(void);
void f_nodo_0x0E(void);
void f_nodo_0x0F(void);
void f_instruc_MODBUS(void);
void f_checa_lista(void);
void f_checa_medidor(int k);
void f_conecta_medidor();
byte lista_verificacion[256][16]; // MATRIZ para registrar los medidores

int min,min_ant,k=255,timmer_checar;
//////////////////////////////////// Variables usadas para recibir los mensajes del MAESTRO
extern int n, // Contador de bytes de mensajes recibidos por Rx de RADIO
timmer; // timmer usado para contar los bytes recibidos
extern byte mensaje_recibido[100];// Mensaje recibido por el Maestro
//////////////////////////////////// Del MENSAJE MODBUS RECIBIDO se extraen:
byte num_disp; // Num. del dispositivo esclavo al que se hace referencia
byte instruc; // Num. de Instrucción o Función
byte datos_recibido[96]; // Bytes de datos_recibido
byte crc[2]; // Valores de CRC a 16 bits
///////////////////////////////////
byte datos_replica[96], // DATOS que serán transmitidos en el MENSAJE REPLICA
*ap_tx; // Apuntador para usar en Tx de RADIO
extern int longitud; // Tamaño final en bytes del mensaje_replica[]
extern byte mensaje_replica[100]; // Mensaje replica para ser aneviado al Maestro
int d; // Tamaño en bytes de los DATOS de mensaje_replica[]
////////////////////////////////////
byte crc_a, crc_b, *ap_crc; // Bytes alto y bajo del CRC calculado
int long_crc; //
static int crc_check; // Variable para chechar si el CRC coinside con el mensaje
int CMDmsj_check,numdisp_check,numdatos_check;
byte error; //
/////////////////////////////////// Variables usadas para recibir los mensajes del MAESTRO
extern int m, // Contador de bytes de mensajes recibidos por Rx de RADIO
timmer2; //
int MODBUSmsj_check; //
extern byte mensaje_aMODBUS[100], // Mensaje transmitido por el RS485
mensaje_deMODBUS[100]; // Mensaje recibido por RS485
byte *ap_txM; //
extern int longitud_MODBUS; //
///////////////////////////////////
int main(void)
{///////////////////////////////
//*** ********************************************************************
PE_low_level_init();// Inicialización de Processor Expert
//************************************************************************
//
f_inicia_nodoM(); //
//
for(;;){ //
//
f_checa_lista(); // Cada 2 minutos para ver cambios en lista_verificacion
//
if(CMDmsj_check==1) // Se checa si se recibio un mensaje del CMD
f_nvoCMD_mensaje(); // si es asi, se ejecuta f_nvoCMD_mensaje()
} //
//
/**************************************************************************
#ifdef PEX_RTOS_START
PEX_RTOS_START(); // Lineas de Precessor Expert no modificables
#endif
/*************************************************************************
}
void f_inicia_nodoM(void)
{//////////////////////////////////////
208
byte i,j,Dato; //
IFsh1_TAddress direccion=0xF000; // Posicion en MEMORIA FLASH donde se comenzarán a
//
for(j=1;j>0;j++){ // Medidor 2 en OxF0020, 3 en OxF0030,... ,255 en 0xF0FF0
for(i=0;i<10;i++){ // Se leen registros de Flash buscando Numeros Serie de los
IFsh1_GetByteFlash(direccion + (j*0x10) + i, &Dato);// Medidores agregados, y se copian
lista_verificacion[j][i]=Dato; // en lista_verificacion[]
} //
} //
}//////////////////////////////////////
void f_checa_lista(void)
{///////////////////////////////
TIMEREC time; //
//
TmDt1_GetTime(&time); // Se toma el tiempo
min=time.Min; // especificamente minutos transcurridos
if(min_ant!=min){ // Si hubo un cambio en minutos
min_ant=min; //
timmer_checar++; // se aumenta la variable del tiempo para comprobar los medidores
} //
if(timmer_checar==3){ // Transcurridos 3 minutos
k=2; //
timmer_checar=0; // y el contador de minutos
} //
//
if(k>0){ //
f_checa_medidor(k); // Se vereificara el medidor en la direccion k MODBUS si existe
k++; //
if(k==256) // si ya se revisaron las 255 posiciones de lista_verificacion
k=0; // se resetea el contador
} //
}///////////////////////////////
void f_checa_medidor(int esclavo)

{///////////////////////////////////
int i,j=0,cont=0; // Se escribiran en los registros de 83 al 93
byte msjMODBUS_0x10[19]={esclavo,0x10,0,83,0,5,10,0,0,0,0,0,0,0,0,0,0,0,0};// los 10 digitos
for(i=0;i<10;i++) // de Num. de Serie del medidor registrado en dicha posicion
if(lista_verificacion[esclavo][i]==0) // Se verifica primero que la posicion
j++; // lista_verificacion[esclavo]tenga agregado
// un medidor checando que sus 10 digitos sean diferentes a 0
if(j==10){ // Si existe un medidor agregado en dicha posición se procede a
for(i=0;i<7;i++) // enviar el mensaje de verificacion
mensaje_aMODBUS[i]=msjMODBUS_0x10[i];// Se forma la primera parte del mensaje que será
// enviado por MODBUS
for(i=0;i<10;i++) // Se enexa el Num. Serie guardado en lista_verificacion
mensaje_aMODBUS[i+7]=lista_verificacion[esclavo][i];// con dicha poscion
//
longitud_MODBUS=19; // Longitud en bytes que llevara el mensaje de verificación
do{ //
f_conecta_medidor(); // Se conecta a la red RS485 y se envia el mensaje
// msjMODBUS_0x10
cont++; //
}while(MODBUSmsj_check==0 && cont<3); // Si no se recibe una respuesta
} // se vuelve a realizar el proceso 2 veces mas
}///////////////////////////////////
void f_nvoCMD_mensaje(void)
{///////////////////////////////////
int replicar=0; // variable usada como bandera
TI1_Disable(); // se desactiva la interrupcion por tiempo de 1ms
//
f_analizar_mensaje(); // ejecuta función para analizar mensaje recibido
//
if(numdisp_check==1 && crc_check==1){// Se checa si el CRC y numero de esclavo son correctos.
if(instruc==0x03 || instruc==0x06 || instruc==0x10){// Adicionalmente si se usan las
// instrucciones MODBUS
209
if(MODBUSmsj_check==1) // se checara si se recibio una respuesta de los esclavos

replicar=1; // y si es asi se formara replica
}else //
replicar=1; //
} //
//
if (replicar==1) { // Si se cumplen las condiciones se formara una respuesta
f_formar_replica(); // ejecuta función para formar el mensaje de replica
//
f_enviar_replica(); // ejecuta función para enviar mensaje de replica
} //
CMDmsj_check=0; // reset a variable para esperar un nuevo mensaje del CMD
n=0; // reset a contador de bytes recibidos
}///////////////////////////////////
void f_analizar_mensaje(void)
{///////////////////////////////////
int i; //
num_disp=mensaje_recibido[0]; // num_disp=mensaje[0];
instruc=mensaje_recibido[1]; // instruc=mensaje[1];
for(i=0;i<(n-4);i++) // datos_recibido[{0},..,{(n-4)-1}]=mensaje[{2},..,{(n-2)-1}];
datos_recibido[i]=mensaje_recibido[i+2];//
for(i=0;i<2;i++) // crc[{0},{1}]=mensaje[{n-2},{n-1}];
crc[i]=mensaje_recibido[(n-2)+i];//
//
f_calcular_crc(n-2, &mensaje_recibido[0]); // Primero calcula el CRC del mensaje recibido
//
crc_check=0; //
if (crc[0]==crc_a && crc[1]==crc_b){
crc_check=1; //
//
f_checar_numdisp(); //
//
if(numdisp_check==1) // si el num. de esclavo coincidio ejecutara la
f_checar_instruc(); // funcion que checa la intruccion MODBUS a ejecutar
} //
}////////////////////////////////////
void f_calcular_crc(int long_crc, byte *ap_crc) // ALGORITMO CRC MODBUS 16 bits

{/////////////////////////////////////////////////////
byte i,j; //
uint16_t crcshift,crcsum = 0xFFFF; //
//
for (i = 0; i < long_crc; i++) { //
crcsum = (uint16_t)(crcsum^(*(ap_crc+i))&0x00FF);
for(j=0;j<8;j++) { //
crcshift = (uint16_t)((crcsum>>1)&0x7FFF); //
if (crcsum&0x0001) //
crcsum = (uint16_t)(crcshift^0xA001); //
else //
crcsum = crcshift; //
} //
} //
crc_a=(crcsum>>8); // El CRC calculado se guarda
crc_b=crcsum; // en 2 varibles de 8 bits
}/////////////////////////////////////////////////////
void f_checar_numdisp(void) // ESTA FUNCION ANALIZA SI EL num_disp ES EL DE UN MEDIDOR EXISTENTE

{//////////////////////////////////////
int i,j=0; //
//
for(i=0;i<10;i++) // si los 10 caracteres de la
if(lista_verificacion[num_disp][i]!=0)// lista_verificacion[num_disp][i]
j++; // son diferentes de 0 si hay un medidor agregado
//
if(j==10 || num_disp==0 || num_disp==1)
numdisp_check=1; //
else //
210
numdisp_check=0; //
}//////////////////////////////////////
void f_checar_instruc(void)
{//////////////////////////// INSTRUCCIONES SOLO VALIDAS PARA EL NodoM: num_disp=1
if (num_disp==1){ //
if (instruc==0x00) // REPROGRAMAR RADIO
if(n==27) // 1(esclavo) + 1(instruccion) + 23(programacion RADIO) + 2(CRC) = 27
f_nodo_0x00(); // ejem: [0x01][0x00][d1][d2][d3]...[d23][CRCa][CRCb]
else //
error=0x03; //
else if (instruc==0x0A) // EXPLORAR NodoM
if(n==6) // 1(esclavo) + 1(instruccion) + 2(0x00,0x00) + 2(CRC) = 6
f_nodo_0x0A(); // ejem: [0x01][0x0A][0x00][0x00][CRCa][CRCb]
else //
error=0x03; //
else if (instruc==0x0B) // VERIFICAR MEDIDOR EN BASE POSICION
if(n==6) // 1(esclavo) + 1(instruccion) + 1(0x00) + 1(posicion) + 2(CRC) = 6
f_nodo_0x0B(); // ejem, checa posicion 0xFF: [0x01][0x0B][0x00][0xFF][CRCa][CRCb]
else //
error=0x03; //
else if (instruc==0x0C) // ASIGNAR MEDIDOR A POSICION
if(n==15) // 1(esclavo)+1(instruccion)+1(posicion)+10(Num. de Serie)+2(CRC)=15
f_nodo_0x0C(); // ejem, agregar en la posicion 0xFF el medidor “m001XYZ000”:
else // [0x01][0x0C][0xFF][0x6D][0x30][0x30][0x31][0x58]
error=0x03; //[0x59][0x5A][0x30][0x30][0x30][CRCa][CRCb]
else if (instruc==0x0D) // QUITAR MEDIDOR DE POSICION
if(n==6) // 1(esclavo) + 1(instruccion) + 1(0x00) + 1(posicion) + 2(CRC) = 6
f_nodo_0x0D(); // ejem, borrar medidor de posicion 0xFF: [0x01][0x0D][0x00][0xFF][CRCa][CRCb]
else //
error=0x03; //
else if (instruc==0x0E) // BUSCAR MEDIDOR POR NUM. DE SERIE
if(n==14) // 1(esclavo) + 1(instruccion) + 10(Num. de Serie) + 2(CRC) = 14
f_nodo_0x0E(); // ejem, buscar la posicion del medidor “m001XYZ000”:
else // [0x01][0x0E][0x6D][0x30][0x30][0x31][0x58][0x59][0x5A][0x30][0x30][0x30][CRCa][CRCb]
error=0x03; //
else if (instruc==0x0F) // RESETEAR NODO_M
if(n==6) // 1(esclavo) + 1(instruccion) + 1(0x00) + 1(0x00) + 2(CRC) = 6
f_nodo_0x0F(); // ejem, resetar NODO_M: [0x01][0x0F][0x00][0x00][CRCa][CRCb]
else //
error=0x03; // ERROR MODBUS 0x03: datos invalidos, en este caso la longitud
else //
error=0x01; // ERROR MODBUS 0x01: No se reconoce la instrucción
} //
///////////////////////////// INSTRUCCIONES SOLO VALIDAS PARA MEDIDORES: 2 a 255 ó 0 BROADCAST
if(num_disp==0 || num_disp>1) // Si se dirige al dispositivo 0 o del 2 al 255
f_instruc_MODBUS(); // INSTRUCCION MODBUS 0x03, 0x06 o 0x10
}////////////////////////////
void f_nodo_0x00(void) // Programar RADIO de NodoM: istribución en binario

{//////////////////////////////////////
int i; //
//
for(i=0;i<(n-4);i++) //
mensaje_replica[i]=datos_recibido[i];
d=n-4; //
}//////////////////////////////////////
void f_nodo_0x0A(void) // EXPLORA NodoM: N.S.NodoM, cantidad medidores, distribución en binario

{/////////////////////////////////////////
byte cantidad_meds=0; // cantidad medidores en el NodoM
byte posis_nodom[32]; // guarda el estado de los 255 espacios para medidores
int g=0,h=0,i=0,j=0,k=0; // variables locales para checar las 255 posiciones
//
while(g<255){ // Se revisa el primer valor de cada una de las 255
while(j<8){ // posiciones de lista_verificación
if(lista_verificacion[g][0]!=0){ // Mientras se encuentre un cero en dicha posición
if(j==0) // no habrá medidor y se descarta, pero cuando se encuentre
211
k=k+1; // algún valor, entoces se considera que un numero de

if(j==1) // serie ha sido agregado.
k=k+2; //
if(j==2) // Si se encontró algún dispositivo agregado se le busca un
k=k+4; // valor en base de la posición, es decir numero de bit
if(j==3) // dentro de un byte (1,2,4,8,16,32,64,128), y asi se van
k=k+8; // analizando 255 bits que estarían distribuidos a lo largo
if(j==4) // de 32 bytes
k=k+16; //
if(j==5) //
k=k+32; //
if(j==6) //
k=k+64; //
if(j==7) //
k=k+128; //
cantidad_meds++; //
} //
j++; //
g++; //
} //
posis_nodom[h]=k; //
h++; //
j=0; //
k=0; //
} //
//
for(i=0;i<10;i++) // Asigna el Num. de Serie del
datos_replica[i]=lista_verificacion[1][i];// NodoM como primer DATO a enviar
datos_replica[10]=cantidad_meds; // Num. de medidores en el NodoM como segundo DATO
for(i=0;i<32;i++) // Asignan las posiciones ocupadas
datos_replica[11+i]=posis_nodom[i];// dentro de los 256 espacios del NodoM
d=43; // Longitud en bytes de datos_replica: 10(N.S) +
}////////////////////////////////////// 1(cantidad_meds) + 32(distribucion)
void f_nodo_0x0B(void) // VERIFICA POSICION: devuelve Num. Serie del medidor de cierta posición
{//////////////////////////////////////
int i,posicion; // variable local para guardar datos de posición
//
posicion=datos_recibido[1]; //
for(i=0;i<10;i++) //
datos_replica[i]=lista_verificacion[posicion][i];
d=10; // Longitud en bytes de datos_replica: 10(N.S)
}//////////////////////////////////////
void f_nodo_0x0C(void) // ASIGNA MEDIDOR A POSICION (dar de alta):

{//////////////////////////////////////
int i,j,agregado=0; //
int posicion=datos_recibido[0]; // POSICION en la que se pretende agregar un medidor
byte ns[10]; //
IFsh1_TAddress direccion=0xF000; // Direccion en MEMORIA FLASH
//
for(i=0;i<10;i++) //
ns[i]=datos_recibido[i+1]; // Num. de Serie del medidor que se pretende agregar
//
for(i=1;i<256 && agregado!=10;i++){// Se busca en lista_verificacion para ver que dicho Num.
agregado=0; // de Serie no esté ya en alguna de las 255 posiciones
for(j=0;j<10;j++){ //
if(lista_verificacion[i][j]==ns[j])//
agregado++; // si 'agregado' llega a 10, significa que ese Num. de
} // Serie ya están en algún lugar de lista_verificacion
} //
// Las posiciones 0 y 1 están restringidas por lo que
if(posicion!=0 && posicion!=1 && agregado!=10) // solo podrá agregarse medidores
{ // (que no esten ya agregados) de la posición 2 a 255
for(i=0;i<10;i++) // Guarda Num. el Serie del nuevo medidor
lista_verificacion[posicion][i]=ns[i];// en lista_verificacion[]
IFsh1_EraseSector(direccion); // Se borra el sector de Memoria Flash antes de escrbir
for(j=1;j<256;j++){ // Guarda en Flash lista_verificacion[] modificada y completa
212
for(i=0;i<15;i++) //
vector_grabar[i]=lista_verificacion[j][i];
IFsh1_SetBlockFlash(&vector_grabar[0],direccion + (j*0x10),sizeof(vector_grabar));
} //
//
for(i=0;i<2;i++) //
datos_replica[i]=0x00; // si se agrego el nuevo medidor mandará 0x00 como DATO OK
}else //
for(i=0;i<2;i++) // Si se mandan posicion 0 o 1, ó el medidor ya existe en
datos_replica[i]=0xFF; // lista_verificacion se mandará 0xFF 0xFF como DATO ERROR
//
d=2; // Longitud en bytes de datos_replica: 2(OK o ERROR)
}//////////////////////////////////////
void f_nodo_0x0D(void) // BORRA MEDIDOR DE POSICION:

{//////////////////////////////////////
IFsh1_TAddress direccion=0xF000; //
int i,j,posicion; //
//
posicion=datos_recibido[1]; // Guarda POSICION de la que se pretende borrar un medidor
if(posicion!=0 && posicion!=1) { // Posiciones 0 y 1 están restringidas y no pueden borrarse
for(i=0;i<10;i++) //
lista_verificacion[posicion][i]=0x00;// Se borra los datos de la POSICION seleccionada
//
IFsh1_EraseSector(direccion); // Se borra el sector de Memoria Flash antes de escrbir
for(j=1;j<256;j++){ // Guarda en Flash lista_verificacion[] modificada y completa
for(i=0;i<15;i++) //
vector_grabar[i]=lista_verificacion[j][i];
IFsh1_SetBlockFlash(&vector_grabar[0],direccion + (j*0x10),sizeof(vector_grabar));
} //
//
for(i=0;i<2;i++) //
datos_replica[i]=0x00; // Como se elimino al medidor mandará 0x00 0x00 como DATO OK
}else{ //
for(i=0;i<2;i++) // Si se escogieron posiciones 0 o 1
datos_replica[i]=0xFF; // mandara 0xFF 0xFF como DATO ERROR
} //
d=2; // Longitud en bytes de datos_replica: 2(OK o ERROR)
}//////////////////////////////////////
void f_nodo_0x0E(void) // BUSCAR MEDIDOR POR NUM. DE SERIE:

{//////////////////////////////////////
int i,j,agregado; //
byte ns[10]; //
//
for(i=0;i<10;i++) //
ns[i]=datos_recibido[i]; // Guarda Num. de Serie del medidor que se pretende encontrar
for(i=1;i<256 && agregado!=10;i++){// Busca en toda la lista_verificacion dicho Num. de Serie
agregado=0; //
for(j=0;j<10;j++){ // si 'agregado' llega a 10, significa que los 10 digitos
if(lista_verificacion[i][j]==ns[j])// del Num. de Serie si están en el lugar 'i' de la
agregado++; // lista_verificacion
} //
} //
if(agregado==10){ //
datos_replica[0]=0x00; // se forman los DATOS de replica con el valor de la posición
datos_replica[1]=i-1; // donde se encontró el Num. de Serie seguido por un 0x00
}else{ //
datos_replica[0]=0xFF; // si no se encontró el Num. Serie se formará el DATO ERROR
datos_replica[1]=0xFF; // 0xFF 0xFF
} //
d=2; // Longitud en bytes de datos_replica: 2(POS,0x00 o ERROR)
}//////////////////////////////////////
void f_nodo_0x0F(void) // RESETEAR todas las Posiciones de NodoM

{/////////////////////////////////////////////////////////////////////////
213
byte ns_nodom[]={'N','M','0','0','1','a','b','c','0','0',0,0,0,0,0,0};// Num. Serie del NodoM

byte vector_reset[]={0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
byte i,j; //
IFsh1_TAddress direccion=0xF000; // Posicion en MEMORIA FLASH donde se comenzarán a
// guardar los Num. de Serie de los medidores
IFsh1_EraseSector(direccion); // Se borra el sector (obligatorio antes de escrbir)
IFsh1_SetBlockFlash(&ns_nodom[0],direccion + 16,sizeof(ns_nodom)); // N.S. de disp 1 en
// posición 0xF0010 (cada 16 bytes será un medidor)
for(j=2;j>0;j++) //
IFsh1_SetBlockFlash(&vector_reset[0],direccion + (j*0x10),sizeof(vector_reset));
//
f_inicia_nodoM(); //
//
for(i=0;i<2;i++) //
datos_replica[i]=0x00; // ya que cumplió mandará 0x00 0x00 como DATO OK
d=2; //
}/////////////////////////////////////////////
void f_instruc_MODBUS(void) // CONECTA A LOS MEDIDORES POR MODBUS PARA LEER O ESCRIBIR REGISTROS
{//////////////////////////////////////////////
int i; // variable local para guardar datos de posición
//
for(i=0;i<n;i++) //
mensaje_aMODBUS[i]=mensaje_recibido[i]; // Forma mensaje que será enviado por MODBUS,
longitud_MODBUS=n; // este será el mismo que el enviado por el CMD
//
f_conecta_medidor(); // Conecta a red RS485 y se envia la peticion MODBUS
//
if(MODBUSmsj_check==1) // Si la bandera es 1 (se recibio mensaje MODBUS)
for(i=0;i<(m-4);i++) // se forma el mensaje de replica que se enviara
datos_replica[i]=mensaje_deMODBUS[i+2];// de regreso al CMD
//
d=m-4; // El mensaje replica para el CMD sera igual que el
}///////////////////////////////////////////// recibido por MODBUS y con la misma longitud
void f_conecta_medidor(void)
{/////////////////////////////////////////////
m=0; //
MODBUSmsj_check=0; //
//
f_calcular_crc(longitud_MODBUS-2, &mensaje_aMODBUS[0]); // Se calcula el CRC
//
mensaje_aMODBUS[longitud_MODBUS-2]=crc_a; // Se completa el mensaje a enviar por RS485
mensaje_aMODBUS[longitud_MODBUS-1]=crc_b; // con su CRC correspondiente
//
RADIO_Disable(); // Se desactiva la comunicacion con el RADIO
RS485_Enable(); // Se activa comunicacion con RS485
//
ap_txM=mensaje_aMODBUS; // Se apunta al mensaje MODBUS que se va a enviar
RS485_SendChar(*ap_txM); // Se hace el envio MODBUS
timmer2=100; // 100 ms para esperar respuesta de medidor
TI1_Enable(); // Se activa el TimerInterrupt
//
while(timmer2!=0 && MODBUSmsj_check==0) // Se espera por la respuesta MODBUS del medidor
{} //
//
TI1_Disable(); // Se desactiva el Timer Interrupt
//
RS485_Disable(); // Se desactiva la comunicacion RS485
RADIO_Enable(); // Se vueve habilitar la comunicacion con el RADIO
}/////////////////////////////////////////////
void f_formar_replica(void)
{ ///////////////////////////////////////
int i; //
// Solo si la instrucción no es la 0x00
if(instruc!=0x00){ //
mensaje_replica[0]=num_disp; // Identificador del numero de dispositivo
214
mensaje_replica[1]=instruc; // Identificador de la instrucción

//
for(i=0;i<d;i++) // mensaje_replica[{2},..,{(n-2)-1}]=mensaje_error_crc[{0},..,{n-1}]
mensaje_replica[i+2]=datos_replica[i];
//
longitud=d+4; //
long_crc=longitud-2; //
ap_crc=mensaje_replica; //
f_calcular_crc(); // Se calcula el CRC del mensaje_replica
//
mensaje_replica[longitud-2]=crc_a; // Agregando Valor alto del CRC del mensaje_replica
mensaje_replica[longitud-1]=crc_b; // Agregando Valor bajo del CRC del mensaje_replica
} //
else { // si fue la instruccion 0x00
for(i=0;i<d;i++) //
mensaje_replica[i]=datos_replica[i];//
longitud=n-4; // Con la instruccion 0x00 se devolveran unicamente
} // los bytes de DATOS_RECIBIDO
//
ap_tx=mensaje_replica; // apuntando a Mensaje a enviar y envia el dato
RADIO_SendChar(*ap_tx); // apuntado por ap_tx a través del p. serial RS485
} ///////////////////////////////////////
D.3 Código fuente: Events.c

#include "Cpu.h"
#include "Events.h"
#ifdef __cplusplus
extern "C" {
#endif
int n=0,m=0,recibio_datos=0;
byte mensaje_recibido[100],
mensaje_replica[100];
byte mensaje_aMODBUS[100],
mensaje_deMODBUS[96];
int longitud,longitud_MODBUS,timmer,timmer2;
extern byte *ap_tx,*ap_txM;
extern int CMDmsj_check,MODBUSmsj_check;
void Cpu_OnNMI(void)
{
/* Write your code here ... */
}
void RADIO_OnError(void)
{
}
void RADIO_OnRxChar(void)
{
RADIO_TComData ch;
if(RADIO_RecvChar(&ch) == ERR_OK){ //Read received character and send it if no error is
detected
mensaje_recibido[n]=ch;
}
recibio_datos=1;
TI1_Enable();
215
timmer=5;//timmer=5000;
n++;
}
void RADIO_OnTxChar(void)
{
ap_tx++;
longitud--;
if(longitud>0){//if(*ap_tx)
RADIO_SendChar(*ap_tx);
}
}
void TI1_OnInterrupt(void)
{
if(timmer==0 && recibio_datos==1){
CMDmsj_check=1;
MODBUSmsj_check=1;
recibio_datos=0;
}
if(timmer!=0)
timmer--;
if(timmer2!=0)
timmer2--;
}
void RS485_OnError(void)
{
}
void RS485_OnRxChar(void)
{
RADIO_TComData ch;
if(RS485_RecvChar(&ch) == ERR_OK){ //Read received character and send it if no error is
detected
mensaje_deMODBUS[m]=ch;
}
recibio_datos=1;
TI1_Enable();
timmer=5;
m++;
}
void RS485_OnTxChar(void)
{
ap_txM++;
longitud_MODBUS--;
if(longitud_MODBUS>0){
RS485_SendChar(*ap_txM);
}
}
/* END Events */
#ifdef __cplusplus
} /* extern "C" */
#endif
216
Concentrador de medidores digitales para sistema de mediciones remotas Apéndice E
Apéndice E: Configuraciones y
Código fuente del CMD
E.1 Configuración de la Raspberry Pi 2
El equipo que se seleccionó para ser el CMD fue una Raspberry Pi 2 (ver Apéndice B.1) y para
poder utilizarla como computador principal y control y monitoreo de nuestro sistema AMI, se
debieron realizar primero todas las configuraciones pertinentes, las cuales básicamente son las
siguientes:
 Iniciando la Raspberry Pi 2
 Configuración de idioma
 Configuración de zona horaria
 Configuración de teclado
 Configuración de la red
 Instalación de la interfaz remota VNC
 Configuración del puerto i2c
 Instalación del RTC (reloj en tiempo real por sus siglas en ingles)
 Configuración del puerto serial
 Instalación de VSFTPD (Servidor FTP)
E.1.1 Iniciando la Raspberry Pi 2

Puede decirse que esta sección describe los primeros pasos después de haber obtenido una nueva
Raspberry Pi 2, la cual como se describe en el Apéndice B.1 se adquirió con sistema operativo
llamado “Raspbian”, el cual es una versión del sistema operativo libre llamado “Debian”
adecuadamente adaptada a la Raspberry Pi [54].
Para comenzar se requiere conectar a la Raspberry Pi 2 los periféricos necesarios para poderla hacer
funcionar, es decir se requiere conectarle:
 un teclado USB
 un mouse USB
 un monitor HDMI
217
 una conexión de red tipo Ethernet, opcional adaptador USB-WiFi

 una fuente de energía con salida micro USB macho con 2A de corriente nominal
Una vez conectados todos los periféricos necesarios se puede encender la Raspberry Pi para
poder trabajar con ella. La primera vez que se inicia la Raspberry Pi 2, se mostrará una pantalla
negra con una serie de procesos corriendo y finalmente se mostrará una pantalla azul (Raspberry
Pi Software Configuration Tool), desde esta podrán hacerse las primeras configuraciones pero
por ahora se omitirá. Una vez completado el inicio de la Raspberry Pi, se mostrará la pantalla de
inicio de sesión. Los datos que vienen por defecto para iniciar sesión y que debemos ingresar son:
Nombre de usuario: pi
Contraseña: raspberry
Ingresados usuario y contraseña correctos se mostrará acceso a la consola de Linux (se puede ver
la línea de orden: pi@raspberrypi ̴ $), desde la cual se podría comenzar a trabajar vía comandos
aunque por ahora será mucho más fácil trabajar bajo el entorno gráfico de Raspbian, para lo cual
se deberá teclear:
startx
Nota: después de cada comando que se escriba hay que completar la acción con la tecla ENTER.
Una vez ingresado el comando anterior podremos ver en el monitor el entorno gráfico de Raspbian
como se muestra en la figura E.1.
Figura E.1. Pantalla de entorno gráfico de Raspbian en la Raspberry Pi 2
Debido a que la Raspberry Pi será utilizada como el CMD de este trabajo propuesto será necesario
configurar sus parámetros básicos. Respecto al idioma quizá no sea tan importante pero es más
cómodo para un hispanohablante trabajar en el idioma español.
218
La zona horaria si es un punto necesario a ajustar ya que el CMD será también un datalogger que
estará registrando mediciones de múltiples medidores todo el tiempo, para que este registro de
mediciones adquiridas se pueda ver con más sentido es forzoso que tenga una estampa de tiempo,
es decir que tenga registradas la fecha y hora a la que se tomó cada medición por lo que tener bien
ajustadas fecha y hora en base a nuestra zona local (Ciudad de México) será de carácter casi
obligatorio. Respecto al teclado será nuestro periférico de entrada para trabajar con la Raspberry
Pi por lo que si no se tiene seleccionado el teclado correcto no se podrá trabajar bien al momento
de escribir comandos o programar. Finalmente hablando de la red las configuraciones son mínimas
sobre todo si se hará una conexión alámbrica (con un cable Ethernet) directo a un router, más bien
se mostrará aquí como ver la dirección IP que adquiere la Raspberry Pi en dicho router.
De aquí en adelante en lo que respecta a instalaciones nuevas y configuraciones de la

Raspberry Pi se harán por medio de la interfaz de comandos Linux llamada “LXTerminal” (ver
figura E.2) por medio de la cual se teclearán las tareas o archivos a ejecutar o modificar entre
muchas otras utilidades interesantes que todos los sistemas operativos basados en Linux nos
permiten.
Figura E.2. Vista de “LXTerminal”, que se utilizará para los pasos siguientes
E.1.2 Configuración de idioma

 Abriremos por comando la Raspberry Pi Software Configuration Tool, (se muestra en la
figura 4.13) tecleando en la “LXTerminal” lo siguiente:
sudo raspi-config
 Nos abrirá una ventana azul en la que seleccionaremos la opción 4: 4 Internationalisation

Options, ver figura E.3.
Figura E.3. Opciones de Raspberry Pi Software Configuration Tool
219
 Ahora se mostrará una nueva ventana similar a la anterior pero con diferentes opciones de
entre las cuales seleccionaremos: I1 Change Locale , ver figura E.4.
Figura E.4. Opciones dentro de Internationalisation Options
 Se debe buscar primero desmarcar el idioma marcado por defecto: en_US.UTF-8 UTF-8.
Figura E.5. Opción de idioma que viene por defecto
 Hay que seleccionar en su lugar el idioma que se desea dejar, en nuestro caso:
es_MX.UTF-8 UTF-8.
 Una vez seleccionado se abrirá una ventana donde nuevamente hay que seleccionar la
opción escogida anteriormente (figura E.6).
Figura E.6. De nuevo seleccionar la opción es_MX.UTF-8 UTF-8
Hecho lo anterior se ejecutarán los cambios y ya se habrá configurado el idioma (ahora es español
de México) de la Raspberry Pi 2.
E.1.3 Configuración de zona horaria
 Nuevamente ingresar a la herramienta de configuración Raspberry Pi Software

Configuration Tool, donde otra vez hay que seleccionar la opción 4 Internationalisation
Options, y ya dentro de esta se debe entrar en la opción I2 Change Timezone (figura E.4).
 Se abrirá la ventana Configuring tzdata donde escogeremos América (figura E.7).
220
Figura E.7. Opciones de continente dentro de Configuring tzdata
 Se mostrará una segunda ventana Configuración de tzdata donde escogeremos esta vez a
la Ciudad de México (figura E.8).
Figura E.8. Opciones de ciudad dentro de Configuración de tzdata
Hecho lo anterior se ejecutarán los cambios y ahora ya se tendrá ajustada la zona horaria de
trabajo para la Raspberry Pi.
E.1.4 Configuración de teclado
 Para configurar el teclado el método más sencillo es utilizando un archivo de configuración

de sistema para lo cual en vez de ocupar comandos desde la “LXTerminal” simplemente
abriremos el explorador de archivos de Raspbian y entraremos a la carpeta “Home” que se
puede ver directamente desde el escritorio, y dentro de ahí se buscará crea nuevo Archivo
vacío (ver figura E.9).
Figura E.9. Se creará un nuevo archivo dentro de la carpeta “Home”
221
 El nuevo archivo será llamado “x.xsessionrc”, se procederá a abrirlo para escribir en el

(ver figura E.10) lo siguiente: setxkbmap es , hecho eso guardar cambios y cerrar
Figura E.10. Líneas necesarias para configurar al teclado en español
 Ahora se cambiara de nombre al archivo anterior dejándolo como “.xsessionrc”, al hacer

esto el archivo se ocultará.
 Reiniciar el sistema y listo, ahora el teclado estará funcionando con sus teclas en español.
E.1.5 Configuración de red

La Raspberry Pi presenta por defecto una dirección IP dinámica es decir puede cambiar
constantemente por asignación del router en el que se conecte. Esta dirección podría hacerse fija
de manera que siempre se mantendrá igual, pero debido a que durante esta tesis se han hecho
pruebas en diferentes lugares (implica conectarse a diferentes routers) se decidió dejar la dirección
IP dinámica, por lo que hay que obtener esta dirección IP asignada a la Raspberry Pi por el router
cada que se conecte a una nueva red.
Este proceso se podría hacer muy fácil mediante comandos desde la Raspberry Pi, pero debido a
que no siempre será la misma dirección (ya que presenta una dirección IP dinámica) y no se
pretende conectar una pantalla, mouse y teclado cada que se desee saber la nueva dirección IP, el
proceso para saber dicha dirección se hará explorando directamente el router desde Windows. El
proceso se describe a continuación:
 Conectarse con una computadora a la misma red (router) donde se ha conectado la

Raspberry Pi.
 Ejecutar en Windows el comando “cmd” (aunque sean las mismas siglas no tienen nada
que ver con el CMD propuesto en esta tesis) o buscar el programa “símbolo del sistema”
y ejecutar como administrador.
 Se mostrará una pantalla negra donde teclearemos: ipconfig, dando enter se mostrará lo de
la figura E.11, lo que interesa es la dirección IP del router la cual se mostrará como “Puerta
de enlace…”.
222
Figura E.11. Esta es la dirección IP del router o puerta de enlace
 En cualquier explorador de internet (Firefox, Opera, Google Chrome, etc.) escribir la

dirección IP obtenida previamente (figura E.12). De esta manera podremos ingresar a la
interfaz del router en el que está tanto la computadora utilizada como la Raspberry Pi.
Figura E.12. Accediendo la interfaz del router, en este caso se trata de un Huawei modelo HG245H
El siguiente paso es ingresar al router. Independientemente del modelo, la marca o la compañía de

internet que provea el router, todos pedirán un usuario y contraseña para ingresar pero en cada caso
estos datos serán distintos. Se puede buscar el modelo de router en la web y encontrar el usuario y
contraseña que traen de fábrica, esto puede funcionar la mayoría de las veces ya que generalmente
los usuarios domésticos no actualizan dichos datos predefinidos, pero no servirá en aquellas
ocasiones en que los administradores de la red ya hayan cambiado previamente estos datos, en
cualquier caso será necesario el consentimiento del dueño del router.
 Para el caso de esta tesis (el mostrado en la figura E.12) los datos de fábrica para ingresar
son: usuario: root, contraseña: admin. Así que se ingresará al router a través de ellos.
223
 Finalmente buscando apropiadamente en la interfaz del router (figura E.13) se puede ver la
lista de dispositivos conectados al router y entre ellos encontrar a la Raspberry Pi, para este
ejemplo se ve que su dirección IP es la 192.168.100.6.
Figura E.13. Lista de dispositivos conectados al router, se puede ver entre ellos a la Raspberry Pi
Los últimos dos pasos (ingresar al router y explorar sus dispositivos conectados) serán muy
diferentes en cada situación como ya se mencionó previamente. El ejemplo aquí mostrado se basa
en el caso especial de este trabajo de tesis. Si el lector quisiera llevar a cabo estos pasos en su propia
red deberá buscar primero los datos y procedimientos de su router en específico y averiguar si
cuenta con los permisos suficientes para ingresar a él.
E.1.6 Instalación de VNC

Ya se inició la Raspberry Pi y se le realizaron los primeros ajustes de idioma y zona horaria, pero
hasta ahora la Raspberry Pi se ha manejado como una computadora personal, es decir se tiene una
tarjeta principal en la que se le conectaron periféricos de entrada (mouse y teclado) y de salida
(monitor). Debido a los propósitos de este proyecto de tesis se requiere que esta Raspberry Pi o
mejor dicho el CMD pueda ser operado de forma remota, si un usuario debidamente autorizado
puede acceder al CMD debería poder hacerlo sin necesidad de estar frente al equipo y conectándole
periféricos de entrada y salida adicionales solo para realizar algunos ajustes.
La idea entonces es la de utilizar un programa denominado escritorio remoto por medio del cual
podemos usar una computadora local (denominada cliente) para acceder a otra denominada
224
(servidor), prácticamente se podrá manejar la computadora remota como si se estuviera trabajando

en ella misma, se podrán ejecutar programas, leer, modificar, crear o borrar archivos y directorios,
todo esto a través de una red informática que trabaje bajo TCP/IP.
En el mercado hay varios programas escritorio remoto, pero el que será instalado y utilizado para
el CMD de esta tesis se llama VNC (Virtual Network Computing por sus siglas en inglés). Es la
mejor opción ya que es un software de licencia libre compatible con casi todos los sistemas
operativos actuales incluyendo Raspbian. VNC le permitirá al administrador transmitir los eventos
creados por el mouse y teclado de su computadora personal hasta el CMD y recibir de este las
imágenes de su pantalla, todo visualizado desde una ventana permitiéndole así trabajar en la
Raspberry Pi como si estuviera directamente en ella.
Se describe a continuación el proceso para instalar VNC en la Raspberry Pi para poder operarla
después de manera remota [55].
 Se abrirá la terminal “LXTerminal” para poder trabajar con comandos, el primero será para
instalar el programa TightVNC, y se realizará tecleando:
sudo apt-get install tightvncserver
 Este comando habrá instalado el VNC en la Raspberry, ahora hay que ejecutarlo
escribiendo en la “LXTerminal”:
Tightvncserver
 La primera vez pedirá una contraseña opcional de 8 dígitos la cual será la contraseña
necesaria para ingresar de aquí en adelante, en este caso se eligió:
raspberr
Hasta este punto ya está instalado el servidor TightVNC pero este necesita ser ejecutado por
comando antes de que permita su acceso remoto, por lo que hay que hacer que este proceso sea
automático desde el momento en que se enciende la Raspberry Pi. A continuación los pasos para
hacerlo:
 Ingresar como súper usuario desde la “LXTerminal”, esto se hará escribiendo:

sudo su
 Entrar al directorio /etc/init.d/
cd /etc/init.d/
 Una vez dentro se debe crear un nuevo archivo y escribir el contenido de la tabla E.1:
225
Tabla E.1. Líneas necesarias para hacer al programa VNC ejecutable desde el arranque del CMD
#! /bin/sh
# /etc/init.d/vncboot
### BEGIN INIT INFO

# Provides: vncboot
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start VNC Server at boot time
# Description: Start VNC Server at boot time.
### END INIT INFO
USER=pi
HOME=/home/pi
export USER HOME
case "$1" in
start)
echo "Starting VNC Server"
#Insert your favoured settings for a VNC session
su - $USER -c "/usr/bin/vncserver :1 -geometry 1280x800 -depth 16 -pixelformat rgb565"
;;
stop)
echo "Stopping VNC Server"
/usr/bin/vncserver -kill :1
;;
*)
echo "Usage: /etc/init.d/vncboot {start|stop}"
exit 1
;;
esac
exit 0
 El archivo deberá guardarse, puede llamarse vncboot por ejemplo.
 Se hará ejecutable tecleando: chmod 755 vncboot
 Se activará la secuencia de arranque basado en dependencia:
update-rc.d lightdm remove

update-rc.d vncboot defaults
 Si permitió la secuenciación de arranque basado en la dependencia correctamente, se

mostrará el siguiente mensaje:
update-rc.d: using dependency based boot sequencing
 Finalmente reiniciar la Raspberry Pi y proceder con la instalación de VNC en la

computadora personal que fungirá como administrador remoto.
Ahora, en el equipo que actuará como host remoto, es necesario instalar y ejecutar el cliente VNC
para el respectivo sistema operativo. En Windows o Mac se debe descargar e instalar un programa
226
cliente VNC. Uno de los más utilizados es TightVNC y se puede descargar de tightvnc.com, de
donde se debe buscar la opción adecuada dependiendo el sistema operativo. [53]
 Durante la instalación seleccionar “custom setup” y dar clic en “TghtVNC Server” para
entonces seleccionar la opción “Entire feature will be unavailable” (ver figura E.1 4).
Figura E.14. Es obligatorio seleccionar esta opción
 Con lo anterior se asegura solo instalar el programa cliente y no el servidor también. Ya

instalado el cliente VNC se necesitará ejecutarlo, se mostrará una pantalla como la de la
figura E.15. En ella hay que introducir la dirección IP de la Raspberry Pi obtenida en la
sección E.1.5 seguida por el número de pantalla (0 o 1, en este caso fue el 0).
Figura E.15. Pantalla inicial de TightVNC, donde se teclea la dirección IP de la Raspberry Pi
 Dar clic en “Connect”, si la IP y pantalla son correctas se abrirá una nueva ventana (figura
E.16) pidiendo la contraseña anteriormente registrada (raspberr).
227
Figura E.16. Pantalla de autentificación para ingresar a la Raspberry Pi
 Finalmente se podrá acceder al escritorio remoto Raspbian donde se podrá trabajar como
si se estuviera haciéndolo directamente en la Raspberry Pi (figura E.17), con este punto ya
se puede tener a nuestro CMD como un sistema remoto.
Figura E.17. Escritorio remoto de la Raspberry Pi corriendo desde una PC con Windows gracias a TightVNC
E.1.7 Configuración del puerto I2C

I2C es un bus multi-dispositivo que se utiliza para conectar periféricos de baja velocidad a las
computadoras y sistemas embebidos (en este caso es para conectar el RTC de la sección E.1.8). La
Raspberry Pi 2 es compatible con esta interfaz en sus conectores (headers) GPIO y es una manera
muy práctica de conectar sensores y dispositivos [55]. Una vez configurado este bus puede conectar
a más de un dispositivo sin necesidad de utilizar pines adicionales de los conectores (headers)
GPIO. Al igual que para cualquier otro dispositivo I2C se debe configurar la interfaz I2C de la
Raspberry Pi 2. El procedimiento será el siguiente [56]:
 En la “LXTerminal” teclear: sudo raspi-config

 Se mostrará la pantalla de la figura 4.13 en la sección 4.4.2, entonces seguir los pasos
siguientes:
Seleccionar: “8 Advanced Options”
Seleccionar: “A7 I2C”
228
Seleccionar: “Yes”
 Otra pantalla preguntará si se desea que la interfaz sea habilitada:
Seleccionar: "Yes"
Seleccionar: "OK"
 Una nueva pantalla preguntará si se desea que el módulo se cargue por defecto:
Seleccionar: "Yes"
 La pantalla indicará que el módulo será cargado por defecto:
Seleccionar: "OK"
Seleccionar: "Finalizar"
 Después de lo anterior volverá a la línea de comandos, y entonces solo falta reiniciar a la

Raspberry Pi para que sea cargado el módulo I2C.
 Es recomendable instalar las últimas actualizaciones de Raspbian así como herramientas

para el manejo del puerto I2C, lo cual se hará tecleando en la “LXTerminal” lo siguiente:
sudo apt-get update

sudo apt-get install -y python-smbus i2c-tools
E.1.8 Instalación de RTC

La Raspberry Pi es capaz de actualizar su fecha y hora utilizando NTP (Network Time Protocol)
solo mientras esté conectada a Internet. Pero cuando esta conexión no está disponible dichos
valores se perderán en cuanto la Raspberry Pi sea reiniciada ya que no hay ningún componente en
su hardware capaz de mantener dichos datos de tiempo. Lo anterior se convierte en un problema
cuando se está trabajando en sistemas que generan registros (datalogger) con estampas de tiempo,
es decir que necesitan saber la fecha y hora exacta de cuando los datos son guardados.
Esto puede solucionarse utilizando un módulo de reloj de tiempo real o RTC (Real Time Clock)
por sus siglas en inglés. Este utiliza un circuito integrado alimentado por una pequeña pila de botón
que mantiene los datos de tiempo incluso si la Raspberry Pi está apagado. Cuando la Raspberry Pi
se reinicia, puede configurar su propio reloj interno utilizando el tiempo que se mantuvo en el RTC.
La forma más fácil de implementar un RTC es comprar un módulo embebido. Afortunadamente
estos módulos RTC son relativamente baratos, fáciles de obtener y conectar con la Raspberry Pi 2.
Módulos basados en los chips DS1307 y DS3231 son dispositivos populares aunque debido a su
229
mayor precisión y compatibilidad con 3.3V un módulo basado DS3231 será el más recomendable
(ver Apéndice B.5). El proceso para instalar este reloj en la Raspberry Pi se describe a continuación:
 Es necesario editar el archivo de módulos, a este entraremos tecleando con la
“LXTerminal”:
sudo nano /etc/modules
 Hecho esto se abrirá un archivo con los módulos que se arrancarán desde el inicio (ver
figura E.18), en él se deben escribir al final las 5 líneas (nombres de módulos) siguientes:
snd-bcm2835
i2c-bcm2835
i2c-dev
rtc-ds1307
i2c-bcm2708
Figura E.18. Archivo modules ya con los nuevos módulos agregados
 Agregados los módulos se debe guardar y salir, esto puede hacerse presionando CTRL +
X, después presionando la tecla Y y finalmente ENTER.
 Se deberá apagar la Raspberry Pi para entonces poder conectar el módulo RTC DS3231 en
las terminales correspondientes (ver sección 3.3.3), y entonces encenderla otra vez.
 Verificar si el puerto I2C está habilitado tecleando:

lsmod | grep i2c_
 Si todo ha salido bien se mostrará “i2c_bcm2708” lo cual significa que los módulos el i2c
están corriendo desde el inicio (figura E.19).
Figura E.19. Se muestran activos los módulos i2c
 Se probará la interfaz para explorar a todas las posiciones i2c esclavo (tanto las vacías
como las ocupadas) tecleando:
sudo i2cdetect -y 1
230
 Se mostrará una tabla (figura E.20) donde se despliegan todas las posiciones i2c entre
ellas la del RTC agregado (está en la posición 0x68).
Figura E.20. Tabla de posiciones I2C ocupadas por algún dispositivo
 Para instalar al DS3231 correctamente en la Raspberry Pi primero se quitará de la lista al

dispositivo i2c-bcm2708, esto se hace borrándolo o agregando un # al comienzo de la línea.
Esto dentro del archivo /etc/modprobe.d/raspi-blacklist.conf, para hacerlo el comando a
teclear en la “LXTerminal” será el siguiente:
sudo sed -i 's/blacklist i2c-bcm2708/#blacklist i2c-bcm2708/' /etc/modprobe.d/raspi-blacklist.conf
 Se carga el módulo i2c-bcm2708: sudo modprobe i2c-bcm2708
 Se notifica al sistema que se agrega un nuevo dispositivo en la posición i2c 0x68:
echo ds3231 0x68 | sudo tee /sys/class/i2c-adapter/i2c-1/new_device
 Nuevamente reiniciar la Raspberry Pi y ejecutar el comando:

sudo i2cdetect -y 1
 Se volverá a mostrar la tabla de dispositivos i2c agregados pero esta vez en la posición 0x86
se mostrará UU (figura E.21) lo cual significa que el reloj DS3231 ha sido agregado
correctamente.
Figura E.21. Ahora se muestra UU en la posición 0x86
 La fecha y hora que tiene el nuevo módulo RTC se puede ver con:
sudo hwclock
 Ahora hay que obtener la hora correcta, esta se puede tomar desde internet (para esto se
necesitará conexión) escribiendo:
sudo ntpd –gq
 O bien se puede introducir manualmente:
231
sudo date -s "Sep 27 2014 12:46:00"
 Llevados a cabo cualquiera de los dos métodos anteriores solo resta cargar esa fecha y hora
al RTC DS3231:
sudo hwclock -w
 Finalmente hay que asegurar que el RTC sea quien esté asignando el tiempo a la Raspberry
Pi desde que esta inicia se deberá editar otro archivo de sistema al cual hay que acceder
mediante:
sudo nano /etc/rc.local
 Nos abrirá el archivo mostrado en la figura E.22, al cual hay que escribir justo antes de la
línea que dice exit 0 las siguientes 2 líneas:
echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-1/new_device

hwclock -s
Figura E.22. Archivo rc.local con las 2 nuevas líneas agregadas
 Guardar y salir, esto puede hacerse presionando CTRL + X, después presionando la tecla
Y y finalmente ENTER.
En este momento ya se tiene listo y funcionando al DS3231 y será quien proporcione la fecha y
hora a la Raspberry Pi salvo que se modifique la configuración posteriormente.
E.1.9 Configuración del puerto serie

La comunicación entre el CMD y los NodoM se realiza por medio de los radios LoRa (ver sección
2.4.5.2), la conexión entre el radio central y el CMD se hace por de comunicación serial para lo
cual se necesita habilitar previamente a la Raspberry Pi para que soporte este medio.
232
Los pines (GPIO 14 y 15) de la Raspberry Pi ya están definidos y configurados como Tx y Rx

UART pero están restringidos para otra aplicación, si requerimos usarlos con programas
adicionales será necesario liberarlos para lo cual se describe la siguiente metodología:
 Primero se debe hacer un respaldo del archivo de configuración original (cmdline.txt) que
contiene los parámetros del kernel, la copia es con el fin de recuperar la configuración
inicial por si se presentará algún inconveniente. Se deberá crear una copia de dicho archivo
con un nombre como por ejemplo cmdline_copia.txt. Para hacerlo por comandos se
tecleará lo siguiente:
sudo cp /boot/cmdline.txt /boot/cmdline_copia.txt
 Después de respaldarlo se debe abrir el original:

sudo nano /boot/cmdline.txt
 De este se eliminarán los siguientes parámetros: “console=ttyAMA0,115200” y

“kgdboc=ttyAMA0,115200”. El archivo cmdline.txt modificado y con los cambios
guardados quedará así:
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p6 rootfstype=ext4 elevator=deadline rootwait
 Ahora se debe editar el archivo que contiene los datos de la consola serial, este es inittab
sudo nano /etc/inittab
 En este se pondrá como comentario la última línea que dice: “2:23:respawn:/sbin/getty -L

ttyAMA0 115200 vt100”, se muestra en la figura E.23:
Figura E.23. Archivo inittab con la última línea comentada
 Guardados los cambios se procederá a reiniciar la Raspberry Pi. Hecho esto se habrán
liberado los pines UART.
233
 Para verificar que los pines envíen y reciban datos UART se instalara la herramienta
llamada minicom. Para utilizarla de forma rápida se deben puentear los pines Rx y Tx (14
y 15), así se recibirán los mismos datos que se transmiten. Par instalar Minicom por
comando teclear:
sudo apt-get install minicom
 Ya instalado se procede a ejecutarlo activando ciertos parámetros:
minicom -b 115200 -o -D /dev/ttyAMA0
 Los parámetros que usamos en la línea anterior abrirán la consola de minicom figura E.24
y significan:
-b 115200 = velocidad de transmisión de datos medida en baudios.
-D /dev/ttyAMA0 = Es el puerto serie.
Figura E.24. Terminal de Minicom donde se pueden teclear valores ASCII con el teclado y si todo está bien se
deberán visualizar en la misma pantalla
 Finalmente se instalará la herramienta serial de python (requiere conexión a internet) para

que el módulo serial pueda ser importado y usado en python usando “import serial”. En la
terminal el código a teclear es:
sudo apt-get install python-serial
Hasta este punto ya se tiene disponible la comunicación serie de la Raspberry Pi para poder
conectarle y usar los radios LoRa mediante programación en “Python”.
E.1.10 Instalación de VSFTPD

Utilizaremos vsftpd, es un servidor FTP (ver sección 2.4.4) para sistemas tipo Unix, incluyendo
Linux, y su nombre proviene de las siglas en inglés Very Secure FTP Daemon. En comparación
con otros programas de servidor ftp, vsftpd está construido para ser especialmente eficaz y muy
seguro. El proceso se enlista a continuación:
234
 Abrir la “LXTerminal” e instalar vsftpd mediante comando (requiere conexión a

internet):
sudo apt-get install vsftpd
 Para configurar vsftpd hay que abrir y editar su archivo de configuración vsftpd.conf:
nano /etc/vsftpd.conf
 Los parámetros que se deben buscar y modificar en vsftpd.conf son:
listen = YES #Para que se inicie con el sistema.

anonymous_enable = NO #No permitir que usuarios anónimos puedan conectarse a nuestro
servidor. Es por seguridad.
local_enable = YES #Permite conectarse con los usuarios locales del servidor donde está
instalado.
write_enable = YES #Si quieres que los usuarios puedan escribir y no sólo descargar cosas.
local_umask = 022 # Esta máscara hace que cada vez que se suba un archivo, sus
permisos sean 755. Es lo más típico en servidores FTP.
 Como paso siguiente hay que crear un grupo de usuario para FTP al cual llamaremos
también FTP, en este caso los usuarios que se conectarán no tendrán acceso al servidor vía
SSH, por lo tanto debemos darles permisos especiales dentro de este grupo.
sudo groupadd FTP
 Se crea una shell fantasma (se refiere a un directorio único para que los usuarios que entren
al servidor FTP no pueden ver otras carpetas de la Raspberry Pi) para que no puedan entrar
a la consola del servidor:
sudo mkdir /bin/FTP
 Se editará el listado de shells del sistema, para ello hay que ingresar al archivo shells:
sudo nano /etc/shells
 Agregamos nuestra shell fantasma al final del archivo que se abrió (ver figura E.25):
Figura E.25. Archivo shells en el que se agregó /bin/FTP
235
 Se debe crear un directorio para el usuario que entrará al servidor, esta será la carpeta a la
que se tendrá acceso vía FTP.
mkdir /home/FTP/CMD_00
 Se le asignan los permisos correspondientes a las carpetas antes creada:

chmod -R 777 /home/FTP/CMD_00
chmod a -rwx /home/FTP
 Se crea un usuario que pertenece al grupo FTP

sudo useradd -g ftp -d /home/FTP/CMD_00 CMD_00
 Para entender los parámetros usados en la línea anterior:

-g FTP = el usuario pertenece al grupo FTP.
-d /home/FTP/CMD_00 = El directorio principal del usuario es /home/ftp/usuarioftp.
CMD_00 = la última palabra será el nombre de usuario
 Solo resta crear la contraseña para el usuario CMD_00:

sudo passwd CMD_00
 Para este trabajo se uso como contraseña: raspberry
Finalmente ya se tiene un servidor FTP en la Raspberry Pi, para realizar las pruebas
correspondientes ver sección 5.4. Será este servidor al que se accederá remotamente para poder
ver los archivos generados por el datalogger.
236
E.2 Código fuente: datalogger.py
Bibliotecas PYTHON a utilizer
Configuración de Puerto serial
Variables globales
Ver algoritmo con diagrama de

flujo y descripción detallada en
la sección 4.5.1.2
Ver algoritmo con diagrama de

flujo y descripción detallada en
la sección 4.5.1.3
237
Ver algoritmo con diagrama

de flujo y descripción
detallada en la sección
4.5.1.4

4.5.1.5

4.5.1.6
238

4.5.1.7
239
240
Concentrador de medidores digitales para sistema de mediciones remotas Apéndice F
Apéndice F: Configuraciones de los

radios LoRa
En el Apéndice A.2 se describe con detalle sobre la tecnología LoRa, y en el Apéndice B.3 se habla
a grandes rasgos sobre las características principales del RF1276T, el cual es el módulo de radio
LoRa utilizado para este trabajo. En esta sección se detallará sobre las configuraciones y el proceso
utilizado para que estos radios LoRa pudieran funcionar en la AMI propuesta de esta tesis.
F.1 Herramientas utilizadas

El proceso de configurar una red LoRa utilizando los módulos de “appconwireless” es bastante
sencillo, y las herramientas de hardware utilizadas para esto fueron:
 Computadora con sistema operativo WINDOWS 8.1

 Convertidor UBS-Serial con chip PL2303HXD o CP2102 (ver en Apéndice B.9)
Mientras que por el lado de software:
 RF Tool, provisto por el fabricante de módulos “Appconwireless”

 SSCOM32e, descargado de la página web del desarrollador aunque bien podría usarse
cualquier terminal que permita enviar mensajes completos mediante comunicación serial
F.2 Configuración de los RF1276T usando una PC

En el Apéndice F.3 se habla de los datos que pueden ser modificados en un chip de tecnología
LoRa, en esta sección se muestran el procedimiento y los datos que fueron seleccionados y
programados en los módulos RF1276T para poder crear la red LoRa que se utilizó en esta tesis.
Los usuarios podrán configurar los parámetros (frecuencia, velocidad de datos, potencia de salida,
Factor RF, ancho de banda, etc.) a través de una PC o del circuito host (el CMD o el NodoM por
ejemplo).
El RF1276T actúa como un puerto UART/TTL por lo que su configuración por medio de una PC
se podrá hacer utilizando un adaptador USB-UART. Existen muchos circuitos de este tipo aunque
la recomendación para este caso es utilizar alguno que tenga el circuito integrado CP2102 (figura
4.3) o el PL2303HXD (figura 4.4), ya que estos son compatibles con las más nuevas versiones del
241
sistema operativo Windows (8.1 y 10) donde incluso se comportan como dispositivo “plug and
play” descargando e instalando automáticamente el driver necesario para su buen funcionamiento,
en caso contrario los controladores se encuentran fácilmente en los sitios web de los fabricantes
del chip respectivo.
Figura F.1. Adaptador USB-UART con el circuito integrado CP2102
Figura F.2. Adaptador USB-UART con el circuito integrado PL2303HXD

y conector especial para radios de appconwireless
 Se procederá conectando el adaptador USB-UART PL2303HXD (fue el chip utilizado) a

algún puerto USB de la computadora que se utilizará.
 Verificar que el sistema operativo haya reconocido e instalado al adaptador USB-UART:
Figura F.3. En el administrador de dispositivos de Windows

deberá aparecer el adaptador como un puerto COM
242
 Una vez listo el adaptador se procederá a conectarlo con el RF1276T, figura F.4:
Figura F.4. Conexión del RF1276T con el convertidor USB-UART para programarlo
 Abrir como administrador la herramienta RF Tool. Se muestra en la figura F.5 así como
los botones y opciones para configurar con las que cuenta.
Factor de dispersión LoRa. Valores mayores

significan sensibilidad más alta, pero
Modo de trabajo: Frecuencia mayor el tiempo de transmisión al aire
estándar, central, nodo
Configuración del Ancho de banda

Puerto serie de la LoRa. Valores
PC: no. de puerto, mayores equivalen a
velocidad de menor sensibilidad.
transmisión y Se recomienda 125K.
paridad.
Número ID de la
Número ID del
red de trabajo
nodo en especifico
Duración de la Ajusta la potencia de

trasnmisión salida. Hay 7 niveles.
“despertador” El 7 es el máximo de
potencia de salida --
Configuración de 20dBm mientras que
la salida serie del el 0 es el más bajo.
módulo: velocidad
de transmisión y
paridad.
Figura F.5. Herramienta RF Tool utilizada para configurar los radios RF1276T
 Inicialmente RF Tool se mostrará en la parte inferior izquierda como “Closed”, así que se
procederá seleccionando el puerto COM en el que está el adaptador USB-UART, se
selecciona la velocidad de programación (se dejó la velocidad por defecto que es 9,600
Bauds) y después dando clic en el botón “Open”, si todo está bien RF Tool detectará al
243
RF1276T y entonces mostrará “Opened” así como los datos de configuración que el radio
tiene configurados en ese momento. Figura F.6.
Figura F.6. Si todo está bien nos mostrará “Opened”
 Ahora dar clic en el botón “Read All” (tener mucho cuidado de no dar clic aun en “Write
All”), hecho esto nos deberá mostrar “Successful” (Figura F.7) y entonces se podrán
modificar todos los datos de configuración mostrados en RF Tool. En la tabla F.1 se
muestran los datos seleccionados para configurarse en los radios RF1276T del CMD y de
dos NodoM utilizados en este proyecto.
Tabla F.1. Parámetros a configurar en los radios RF1276T
CMD NodoM 0x0002 NodoM 0x0003
Parámetros de radio
RF_Frequency 916 MHz 916 MHz 916 MHz
RF_Factor 2,048 fragmentos 2,048 fragmentos 2,048 fragmentos
RF_BW 125 Kbs 125 Kbs 125 Kbs
RF_ Mode Central Node Node
Parámetros de red
Node ID 1 2 3
Breath 2s 2s 2s
Net ID 1 1 1
Power 7 7 7
Parámetros de puerto serial
BaudRate 9,600 9,600 9,600
Parity no no no
Como se puede ver en la tabla 4.80 el radio para el CMD se programará en modo central, mientras
que el de los NodoM será en modo node.
 Finalmente estos se cargarán al RF1276T dando clic en el botón “Write All”.
244
Figura F.7. Si todo va bien mostrará “Successful”
 El proceso se realizará en 3 RF1276T, la tabla 4.80 muestra los datos a poner en cada uno.
En la sección 5.3 se muestran las pruebas realizadas a los radios LoRa RF1276T.
F.3 Configuración de los RF1276T por mensaje

Otra forma de cambiar los parámetros de configuración de los radios LoRa es por medio de un
mensaje de configuración transmitido de forma serial, este mensaje puede ser transmitido por
cualquier equipo que este comportándose como el “host” del radio RF1276T. Entiéndase por
“host” a una computadora, MCU (Micro Controller Unit por sus siglas en inglés) o cualquier
dispositivo programable capaz de controlar periféricos y manejar comunicación serial. Mediante
estos puede realizarse la configuración de los radios RF1276T enviando un paquete de 23 bytes de
configuración a la terminal RX del RF1276T. El formato del mensaje de configuración de los
RF1276T se muestra en la tabla F.2.
Tabla F.2. Formato del mensaje de configuración para el RF1276T

Sincronización
configuración
Long. DATOS
Check Sum
Comandos
DATOS de
Header
Fin
ID
RF_Power
Longitud
RF_BW
Bauds
Modo
Parity
0x0D
0x0A
0xAF
0xAF
0xAF
0x00
0x00
RF_F
NET
ID1
ID2
CS
F1
F2
F3
X
Como se aprecia en la tabla F.2 los 23 bytes se organizan en las ocho secciones siguientes:
 Sincronización: estos dos bytes forman la palabra 0xAFAF para que el RF1276T identifique
el comienzo un mensaje de reconfiguración.
245
 ID: se debe manejar el ID 0x0000, como si se tratara de un mensaje BROADCAST.

 Header: valor constante con la palabra 0xAF obligatoria pero sin significado especifico.
 Comandos: X (tabla F.3) especifica si el mensaje es petición o respuesta mientras que Y
(tabla F.4) especificará la acción a realizar.
Tabla F.4. Y
0x01 Escribir
Tabla F.3. X 0x02 Leer
0x80 Petición 0x03 Estándar
0x00 Respuesta 0x04 Central
0x05 Nodo
 Longitud de DATOS: longitud en bytes de los DATOS de configuración.

 DATOS de configuración: como se aprecia en la tabla F.2 esta sección consta de 12 bytes
utilizados para expresar: velocidad de transmisión serial en baudios (tabla F.5), paridad de la
comunicación serial (tabla F.6), la frecuencia de trabajo expresada en 24 bits (tabla F.7),
(RF_Factor) número de fragmentos necesarios para formar un bit (tabla F.8), modo de trabajo
(tabla F.9), (RF_BW) el ancho del canal de transmisión (tabla F.10), el ID del nodo expresado
en 16 bits (tabla F.11), red LoRa a la que pertenecerá (tabla F.12) y la potencia de transmisión
(tabla F.13).
Tabla F.6. Tabla F.7. Frecuencia: Tabla F.8.
Tabla F.5. Bauds
Paridad F1,F2,F3 RF_Factor
0x01 1,200 0x00 no 𝑓 0x07 128
0x02 2,400 0x01 impar , ejem: 0x08 256
61.035
0x03 4,800 0x02 par 0x09 512
0x04 9,600 915𝑀𝐻𝑧 0x0A 1,024
0x05 19,200 = 14,991,398 0x0B 2,048
61.035
0x06 38,400 = 0𝑥 𝐸4 , 𝐶0 , 26 0x0C 4,096
0x07 57,600
Tabla F.10. Tabla F.11. Tabla F.12. Tabla F.13.

Tabla F.9. Modo
RF_BW ID1, ID2 NET RF_Power
0x00 estándar 0x06 62.5K 0x0000 a 0x00 a 0xFF 0x01 4 dBm
0x01 central 0x07 125K 0xFFFF 0x02 7 dBm
0x02 nodo 0x08 256K 0x03 10 dBm
0x09 512K 0x04 13 dBm
0x05 14 dBm
0x06 17 dBm
0x07 20 dBm
 Check Sum: últimos dos valores de la suma hexadecimal de: Sincronización, ID, Header,
Comandos, Longitud y DATOS de configuración.
 Fin: se finaliza el mensaje de reconfiguración con los valores 0x0D y 0x0A.
246
F.3.1 Ejemplo de configuración usando mensaje
Se desea reconfigurar un radio RF1276T mediante un paquete de comandos enviados por un MCU
(para este ejemplo en lugar de MCU se utilizará la terminal sscom32e para transmitir el paquete de
reconfiguración), los datos deseados para el radio a configurar son los siguientes:
 Como parámetros UART se quieren 9,600 Baudios, sin paridad.

 La frecuencia de trabajo es 915MHz.
 Los parámetros LoRa deseados son RF_Factor=2,048bits y RF_BW=125KHz
 Se quiere que trabaje en modo nodo con el ID 3, en la red 1 y a máxima potencia.
Solución: en base a los requerimientos deseados se formará el siguiente paquete de datos para la
reconfiguración de un módulo RF1276T
 Los primeros parámetros de configuración son siempre constantes

- Sincronización → 0xAF, 0xAF,
- ID → 0x00, 0x00 y
- Header → 0xAF.
 Se escribirá como Comandos:
- Petición → 0x80 y
- Escribir → 0x01.
 Se sabe que los Datos de configuración miden 12 bytes de
- Longitud → 0x0C
 Los Datos de configuración:
- Bauds = 9,600 → 0x04,
- No Paridad → 0x00,
𝟗𝟏𝟓,𝟎𝟎𝟎,𝟎𝟎𝟎
- f= = 𝟏𝟒, 𝟗𝟗𝟏, 𝟑𝟗𝟖 en hexadecimal → 0xE4, 0xC0, 0x26,
𝟔𝟏.𝟎𝟑𝟓
- RF_F = 2,048 → 0x0B,
- Modo = Nodo → 0x02,
- RF_BW = 125KHz → 0x07,
- ID de Nodo 3 → 0x00, 0x03,
- Net 1 → 0x01
- Potencia ó RF_Power = 20dBm → 0x07.
 Haciendo la suma de todos los bytes anteriores: 0xAF + 0xAF + 0x00 + 0x00 + 0xAF +
0x80 0x01 + 0x0C + 0x04 + 0x00 + 0xE4 + 0xC0 + 0x26 + 0x0B + 0x02 + 0x07 + 0x00 +
0x03 + 0x01 + 0x07 = 0x487, de los cuales solo se toman los últimos dos valores, es decir
- CS → 0x87
 Para el
- Final → 0x0D, 0x0A
247
 El mensaje de configuración completo para enviar en hexadecimal queda:

AF,AF,00,00,AF,80,01,0C,04,00,E4,C0,26,0B,02,07,00,03,01,07,87,0D,0A
 Se envía dicho paquete usando la terminal sscom32e (figura F.8).
Mensaje de
respuesta del
RF1276T, si
solo cambia el
comando
HEADER de Mensaje de
0x80 a 0x00 configuración
significa que se para el
ha configurado RF1276T
correctamente
Figura F.8. Configuración de un RF1276T usando comandos enviados con la terminal SSCOM3.2
248

TESIS-Concentrador de Medidores Digitales para Sistema de Mediciones Remotas

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

TESIS-Concentrador de Medidores Digitales para Sistema de Mediciones Remotas

Hochgeladen von

Copyright:

INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y

“Concentrador de medidores digitales para

QUE PARA OBTENER EL GRADO DE

JUNIO DE 2016, CIUDAD DE MÉXICO

INSTITUTO POLTÉCNICO NACIONAL

CARTA CESIÓN DE DERECHOS

Los usuarios de la información no deben reproducir el contenido textual, gráficas o datos

Si el permiso se otorga, el usuario deberá dar el agradecimiento correspondiente y citar la

Este trabajo en particular se enfocó en la primera etapa conocida como Infraestructura de

El prototipo de Concentrador de Medidores Digitales desarrollado en este trabajo se llamó CMD

Para ti amiga mia, mi compañera y mi futura esposa:

Itzhae Guadalupe López Caso

A mis compañeros, a mis profesores y a la SEPI-ESIME-ZACATENCO en general por darme la

Resumen .............................................................................................................................................................. vii

2.3.4 Servidores FTP .................................................................................................................................. 35

5.3 Pruebas a la red LoRa ............................................................................................................................ 140

Figura 1.1. AMI, componentes, interacción y comunicación entre ellos ..................................................................................... 3

Figura 4.1. Ejemplo del archivo lista_medidores.txt. ............................................................................................................. 115

Figura B.1. Detalle de los puertos GPIO de la Raspberry Pi 2 ................................................................................................. 179

Figura E.1. Pantalla de entorno gráfico de Raspbian en la Raspberry Pi 2 .............................................................................. 218

Tabla 2.1. Diferencias entre Internet, Intranet y Extranet ........................................................................................................ 33

Tabla 4.24. Diagrama de flujo de f_enviar_replica ................................................................................................................. 84

Tabla 4.60. Diagrama de flujo de f_nodo_0x0E ..................................................................................................................... 106

Tabla 5.1. Ejemplo de petición con la instrucción 0x03 ......................................................................................................... 129

Tabla 5.5. Mensaje para desactivar al MedidorE .................................................................................................................. 131

Tabla B.1. Descripción de los pines del RF1276T ................................................................................................................... 182

Tabla C.2. Configuraciones básicas del puerto serial .............................................................................................................. 194

Tabla F.1. Parámetros a configurar en los radios RF1276T ..................................................................................................... 244

SCADA “Supervisory Control And Data Acquisition” (Control de supervisión y

X(t)rms Valor RMS de señal continua en el dominio del tiempo

 Medidor: Obtiene las mediciones eléctricas.

Figura 1.1. AMI, componentes, interacción y comunicación entre ellos

1.2 Objetivos de la tesis

Implementar un prototipo de dispositivo denominado Concentrador de Medidores Digitales

La justificación para esta tesis radica en documentar el diseño e implementación de un dispositivo

1.4 Estado del arte

La implementación de sistemas AMI para la complementación de Redes Eléctricas Inteligentes ha

Italia-Enel, La compañía eléctrica italiana ENEL, a través de un proyecto denominado AMM

celular) y un sistema central de gestión de medidores encargado de realizar la facturación y

Suecia-Vattenfall, La compañía sueca de distribución Vattenfall a través del proyecto

USA-California, En Estados Unidos para el 2013 ya se habían instalado cerca de 37 millones

Polanco 2011, proyecto de implementación de una AMI en la zona residencial y comercial de

medición directa en transformadores de distribución. A la fecha sigue en etapa de expansión

Otras ciudades, En diversos estados como lo son Querétaro, Guanajuato, Aguascalientes,

La norma [24] es una publicación internacional que a través de varias recomendaciones

De manera similar está la [25] la cual ya es un estándar internacional enfocado en las

En la tesis Diseño de Medidor Inteligente e Implementación de Sistema de Comunicación

Contempla el diseño en un sistema embebido de un Concentrador de Medidores Digitales capaz de

1.7 Estructura de la tesis

Capítulo 6: Se dan las conclusiones, aportaciones y recomendaciones para trabajos futuros

Apéndice A: Se describen los sistemas de comunicaciones alámbricos e inalámbricos utilizados,

Capítulo 2: Marco teórico y

2.1 Mediciones Eléctricas

2.1.1 Conversión analógica a digital y muestreo de señales

Señal original en dominio

2.1.2 Valor Eficaz o RMS

Donde x(n) es la función periódica en el dominio de tiempo discreto y N es el número de muestras

2.1.3 Potencia Instantánea

𝑝 = 𝑣(𝑡)𝑖(𝑡) (1.3) 𝑝 = 𝑣(𝑛)𝑖(𝑛) (1.4)

2.1.4 Potencia Activa

2.1.5 Potencia Aparente

𝑆 = 𝑣𝑟𝑚𝑠 (𝑡)𝑖𝑟𝑚𝑠 (𝑡) (1.7) 𝑆 = 𝑣𝑟𝑚𝑠 (𝑛)𝑖𝑟𝑚𝑠 (𝑛) (1.8)

2.1.6 Potencia Reactiva

2.1.7 Tipos de cargas reactivas

2.1.8 Factor de Potencia