Nodemecu/nodemecu
5
0
Fork 0
Code Issues 3 Pull requests 3 Projects Releases Wiki Activity

Readme

Browse source
This commit is contained in:
Sergio Pernas 2022-02-23 11:45:40 -03:00
parent d9963a7ddd
commit fb78ca2ae6
5 changed files with 347 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

BIN
README.img/arduino-nano-pinout.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 58 KiB

BIN
README.img/esquema-pines-gpio.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 267 KiB

BIN
README.img/image 01.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 12 KiB

BIN
README.img/maquina de estados.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 31 KiB

347
README.md Normal file
View file

@ -0,0 +1,347 @@
# Adquisidor
[TOC]
Protocolo de comunicaciones en serie inspirado en el protocolo **1-Wire** para el control de dispositivos adquisidores.
## Especificaciones
Se comparte un único bus de trasporte de tramas entre dispositivos:
- Un dispositivo controlador arbitra el uso y disposición del medio, ademas de enviar órdenes a los dispositivos adquisidores y recibir respuestas.
- Los dispositivos adquisidores vuelcan tramas al medio como respuesta a peticiones del controlador. Estos dispositivos nunca deben ocupar el bus de forma arbitraria.
## Enlace de datos
### Interfaz física
El transporte de datos se realiza por un medio compartido, un único bus conectado a las interfaces Tx y Rx de todos los dispisitivos.
![](/home/sergio/BarraDEV/Proyectos/Plataforma de monitoreo/Adquisidor/README.img/image 01.png)
### Protocolo de solicutd y respuesta (PESR)
La comunicación entre dispositivos es por envío y recepción de dos tipos de tramas bajo un protocolo común:
- Solicitud (Controlador).
- Respuesta (Adquisidor).
Las tramas se componen de 18 bytes:
- Prefijo de sincronización (2 bytes).
- Cabecera (5 bytes).
- Payload (10 bytes).
- Fin de trama (1 byte).
**Nota:** Si bien se contabilizan los bytes de sincronización, estos no son parte de la trama en si mismos.
Las tramas poseen campos comunes para todas las operaciones y dispositivos: prefijo, cabecera y fin de trama. Quedando el campo ‘payload’ para la estructura de datos y los datos.
#### Estructura de trama genérica
| Campo | Tipo de dato | Valor | Dato | Descripción |
| ----- | ------------ | ----- | --------- | ------------------------------------------------------------ |
| | | | | **PREFIJO** |
| 0 | BYTE | 0xAA | Prefijo 1 | Inicio de sincronización. |
| 1 | BYTE | 0xCC | Prefijo 2 | Fin de sincronización. |
| | | | | **CABECERA** |
| 0 | BYTE | | DevID | Id del dispositivo **al que** consulta/responde.<br>Para el controlador siempre es ‘0x00’ (ver **IDs de dispositivos**). |
| 1 | BYTE | | SrcID | Id del dispositivo **que** consulta/responde.<br/>Para el controlador siempre es ‘0x00’ (ver **IDs de dispositivos**). |
| 2 | BYTE | | ReqID | Número de pedido. |
| 3 | BYTE | | Cmd | Número de comando (ver **Tabla de comandos**). |
| 4 | BYTE | | CodErr | Código de error (ver **Error codes**) |
| | | | | **PAYLOAD** |
| 5 | | | Gap[0] | Datos que se tranportan. En caso de campos vacios<br>o de valor *null* se completa con ‘0x00’. |
| ... | | | Gap[..] | |
| 14 | | | Gap[9] | Datos que se tranportan. En caso de campos vacios<br/>o de valor *null* se completa con ‘0x00’. |
| | | | | **FIN TRAMA** |
| 15 | BYTE | | Cks | Campo de verificación de trama por suma simple. |
## Ciclo de control y respuesta
El sistema se compone por un dispositivo *controlador* cuya ID de dispositivo siempre es `0x00`, los dispositivos *adquisidores* deben tener una ID de dispositivo única e irrepetible.
El controlador recorre de forma cíclica los adquisidores solicitando los datos asociados a los sensores.
### Asignación de ID
Todo el sistema se completa como un array de adquisidores, donde el puerto de conexión determina la ID de dispositivo.
| Salida digital Controlador | Adquisidor | ID |
| -------------------------- | ---------- | ---- |
| DO1 | 1 | 0x01 |
| DO2 | 2 | 0x02 |
| DO3 | 3 | 0x03 |
| DO4 | 4 | 0x04 |
El adquisidor recibe (según la salida digital del controlador) una ID que siempre es la misma para el mismo puerto, al intercambiar los adquisidores de puerto se asume un cambio de ID para el adquisidor.
### Adquisidores
Los adquisidores pueden manejar varios sensores, en muchos casos un mismo integrado puede censar múltiples variables, como por ejemplo presión y temperatura. Por lo tanto cada adquisidor al ser consultado va a responder tantas veces como sensores tenga.
```
// Dispositivo adquisidor
int STOTAL=4; // Total de sensores
float SEN01; //Información devuelta por el sensor
float SEN02;
float SEN03;
float SEN04;
byte STYPE01; // Tipo, ej. Temperatura
byte STYPE02;
byte STYPE03;
byte STYPE04;
```
Ver tabla de **tipos de sensores**.
### Solicitud de sensores
1. El controlador envía una **trama de solicitud** con el comando **CON** (ver **tabla de comandos**) y una **ID de dispositivo**.
2. El adquisidor recibe la petición y responde con un comando **ACK**.
3. El controlador responde el **ACK** con un comando **GET**.
4. El adquisidor envía una trama por cada sensor según la **trama de respuesta** con la siguiente información:
- Comando de respuesta **ACK**.
- Total de sensores.
- Valor recogido por el sensor.
- Tipo de sensor.
- Código de error **0x00**.
5. El adquisidor responde con un comando **FIN** con el último envío de datos, entonces el controlador continua con el siguiente adquisidor.
### Manejo de errores
- Cuando el adquisidor no esta listo para recoger datos de los sensores responde con un **FIN** y un código de error **0x01**. El controlador continúa con el siguiente adquisidor.
- Cuando el adquisidor detecta fallos en un sensor o no recibe datos de éste, se responde con un **ACK** , un código de error **0x02** y un valor **ZERO** de recogida para dicho sensor.
### Tiempos de espera
- El controlador espera un máximo de 500 milisegundos antes de pasar al siguiente adquisidor.
## Máquina de estados
### Adquisidor
El adquisidor funciona de forma independiente del controlador en relación a los métodos de medición y las operaciones automatizadas asociadas a dicho proceso de medición: El controlador solicita datos, el adquisidor los provee.
Es importante tener en cuenta que el rol del controlador **no** es realizar mediciones, ni automatizar procesos.
Por lo tanto, el adquisidor se cimienta bajo la estructura lógica de una máquina de estados transductora. Este modelo permite definir un esquema de estados de forma genérica:
- Recepción de datos.
- Procesamiento de datos.
- Ejecución de tareas
- Salida de datos
La máquina de estados deja la libre incorporación de funciones y sub programas que son ejecutados en el estado deseado según la información recibida bajo el protocolo de comunicación PSR.
## Tramas
### Trama de solicitud
Es la trama enviada por el controlador, se establece el comando y se espera respuesta.
| Campo | Tipo de dato | Valor | Dato | Descripción |
| ----- | ------------ | ----- | ------- | ------------------------------------------------------------ |
| 0 | BYTE | | DstID | Id del dispositivo **al que** consulta/responde.<br>Para el controlador siempre es ‘0x00’ (ver **IDs de dispositivos**). |
| 1 | BYTE | 0x00 | SrcID | Id del dispositivo **que** consulta/responde.<br/>Para el controlador siempre es ‘0x00’ (ver **IDs de dispositivos**). |
| 2 | BYTE | | ReqID | Número de pedido. |
| 3 | BYTE | | Cmd | Número de comando (ver **Tabla de comandos**). |
| 4 | BYTE | | CodErr | Código de error (ver **Error codes**) |
| 5 | | | Gap[0] | Datos que se tranportan. En caso de campos vacios<br>o de valor *null* se completa con ‘0x00’. |
| ... | | | Gap[..] | |
| 14 | | | Gap[9] | Datos que se tranportan. En caso de campos vacios<br/>o de valor *null* se completa con ‘0x00’. |
| 15 | BYTE | | Cks | Campo de verificación de trama por suma simple. |
### Trama de respuesta
| Campo | Tipo de dato | Valor | Dato | Descripción |
| ----- | ------------ | ----- | ------- | ------------------------------------------------------------ |
| 0 | BYTE | | DevID | Id del dispositivo **al que** consulta/responde.<br>Para el controlador siempre es ‘0x00’ (ver **IDs de dispositivos**). |
| 1 | BYTE | 0x00 | SrcID | Id del dispositivo **que** consulta/responde.<br/>Para el controlador siempre es ‘0x00’ (ver **IDs de dispositivos**). |
| 2 | BYTE | | TranID | Identificador de transacción. |
| 3 | BYTE | | Cmd | Número de comando (ver **Tabla de comandos**). |
| 4 | BYTE | | CodErr | Código de error (ver **Error codes**). |
| 5 | BYTE | | Stotal | Cantidad de sensores. |
| 6 | BYTE | | Snum | Numero de sensor con el que contesta. |
| 7 | BYTE | | Stype | Tipo de sensor. |
| 8~11 | BYTE | | Value | Valor recogido por el sensor (punto flotante). |
| ... | | | Gap[..] | |
| 14 | | | Gap[3] | Datos que se tranportan. En caso de campos vacios<br/>o de valor *null* se completa con ‘0x00’. |
| 15 | BYTE | | Cks | Campo de verificación de trama por suma simple. |
## Tablas
### Tabla de comandos
| Comando | Decimal | Hexadecimal | Descripción |
| ------- | ------- | ----------- | ------------------------------------------------------------ |
| CON | 170 | 0xAA | Evalúa si hay un dispositivo conectado. |
| ACK | 171 | 0xAB | Como respuesta a un `CON`, se evalúa disponibilidad del dispositivo. |
| GET | 172 | 0xAC | Solicitud de entrega de datos al adquisidor. |
| POST | 173 | 0xAD | Envío de datos al adquisidor. |
| RESET | 174 | 0xAE | Reinicio de adquisidor. |
| FIN | 175 | 0xAF | Fin de entrega de datos. |
| | | | **RESERVADOS** |
| | | | **COMANDOS NO DEFINIDOS** |
| | 190~200 | | Comandos personalizados. |
### Códigos de error
| Código | Decimal | Hexadecimal | Descripción |
| ------- | ------- | ----------- | ------------------------------------------------ |
| Success | 0 | 0x00 | Nada que informar. |
| Espera | 1 | 0x01 | El dispositivo no esta listo para enviar datos. |
| Fallo | 2 | 0x02 | No se puede acceder a la información del sensor. |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
#### Tabla de sensores
| Código | Sensor | |
| ------ | -------------------------- | ---- |
| 0x01 | Temperatura en cetígrados. | |
| 0x02 | Humedad relativa. | |
| 0x03 | Presión. | |
| | | |
## Esquemas de conexión
### Controlador
Raspberry PI 4 GPIO pin out.
| Pin | Tipo | Descripción |
| ---- | ------- | ------------------------------- |
| 4 | Vin 5V | Alimentación. |
| 6 | GND | Retorno alimentación. |
| 8 | UART TX | Bus de datos compartido con RX. |
| 10 | UART RX | Bus de datos compartido con TX. |
| 12 | GPIO18 | Asignador de ID 0x01 |
| 16 | GPIO23 | Asignador de ID 0x02 |
| 18 | GPIO24 | Asignador de ID 0x03 |
| 22 | GPIO25 | Asignador de ID 0x04 |
![](/home/sergio/BarraDEV/Proyectos/Controlador adquisidor/README.img/esquema-pines-gpio.png)
### Adquisidor
Arduino nano v2.3
| Pin | Tipo | Descripción |
| ---- | ------- | ------------------------------- |
| 1 | UART TX | Bus de datos compartido con RX. |
| 2 | UART RX | Bus de datos compartido con TX. |
| 5 | D2 | Receptor ID |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
## API
### JSON
```
{
"transaction_uuid" : "",
"controller_id": "id raspberry";
"timestamp" : "terminadas todas las lecturas",
"error_code" : "value",
"coordinates" : {
"lat": 1,
"lng": 1
},
"battery_status" : "value",
"sample": "si hay muestra para retirar",
"storage": "uso del almacenamiento",
"arduinos": [
{
"id": 1,
"sensores": [
{
"timestamp": 20211017,
"type": "temperatura",
"value": 30,
"unit": "C",
"error": 200
},
{
"timestamp": 20211017,
"type": "humedad",
"value": 100,
"unit": "%"
},
{
"timestamp": 20211017,
"type": "presion",
"value": 70,
"unit": "Hpa"
}
]
},
{
"id": 2,
"sensores": []
}
]
}
```
### URL
```
https://ectomobile.sutty.nl/transactions
```