Estructura de datos para almacenar información de salida

[crisconru]

Crear una estructura para poder configurar el mensaje de salida y que luego la lea directamente la clase encargada de la comunicación serie.
Propongo una Dataclass

[JJ]

¿Por qué el de entrada y salida es diferente? Tal como yo lo entiendo, sólo se lee información del puerto serie para presentarse en el gráfico.

[crisconru]

Porque lo que mandas al respirador, no es lo mismo que recibes.
Tu del respirador recibes cierta información con su correspondiente trama

En cambio lo que le mandas al respirador (si quieres), son parámetros para cambiar su configuración a través de una trama distinta a la de recepción.

Así que como lo había pensado es:

1. Una clase para tener una conexión serial estable que sirva para recibir y enviar.
2. Una clase que sirva para parsear el mensaje de entrada y pueda ser leido cada campo comodamente.
3. Una clase para poder configurar los modos / parámetros que quieras modificar en el respirador, y luego se manda directamente por la clase 1.

[JJ]

Pero es que yo creo que no se envía nada al respirador. Se va recibiendo información cada 0.2 segundos, según leí. Si mandas cosas al respirador estamos en terrenos muy peligrosos.

[crisconru]

Si se manda o se acabará mandando @JJ. Hablando con una enfermera, me comenta que los parámetros del respirador lo tienen que cambiar los anestesis según el paciente este de una manera u otra.

Mira la trama para mandar parámetros, la RX. Tienes un campo Command, para decirle que valor es el que vas a cambiar. Y luego un campo Value, donde les dices que valor toma ese parámetro. La interfaz gráfica táctil es como el anestesista va a configurar el respirador.

Por eso esto no es algo que pueda ir a un quirófano en dos días... (me entiendes por donde voy)

[JJ]

El mar., 31 mar. 2020 a las 12:59, Cristóbal Contreras Rubio (< notifications@github.com>) escribió:

Si se manda o se acabará mandando @JJ <https://github.com/JJ>. Hablando con una enfermera, me comenta que los parámetros del respirador lo tienen que cambiar los anestesis según el paciente este de una manera u otra.

Ya, pero eso he entendido yo que se va a hacer dentro de los dos Arduinos, no desde el PC.

Mira la trama para mandar parámetros, la RX <https://docs.google.com/document/d/1lItbWZhYFjCUJKEzwG3V0N3ZbFNCW4r7WvXlSnQcjlk/edit#heading=h.xgx60y6l5inf>. Tienes un campo *Command*, para decirle que valor es el que vas a cambiar. Y luego un campo *Value*, donde les dices que valor toma ese parámetro. La interfaz gráfica táctil es como el anestesista va a configurar el respirador.

Sí, pero ya dije en los issues del otro repo que eso no es cosa nuestra. No va a haber interfaz gráfica táctil, el programa va a recibir sólo los datos para representar. Insisto, si se van a mandar cosas desde el PC estamos hablando de algo totalmente diferente (y es territorio desconocido donde mejor no meternos)

[JJ]

Esto quizá lo podría aclarar Fede...

[JJ]

Propongo que cerremos esto para centrarnos en la información que nos llega desde el ventilador.

[rafacouto]

Hola @JJ ! Estamos desarrollando un protocolo de interfaz con el monitor en https://gitlab.com/reespirator-arduino/reespirator/-/issues/4 e implementado la clase en C++. A día de hoy aún estamos definiendo campos y no está cerrado del todo pero ahí está el documento con el protocolo de tramas por si os sirve. En cuanto esté cerrada la versión 1 publicaremos la implementación C++.

[JJ]

@rafacouto ¡Gracias por avisar! Ánimo

[rafacouto]

En cuanto si el monitor envía datos al Arduino... al principio se pensó sólo como un visualizador de la gráfica y que el control se realice en una interfaz sencilla con LCD en la parte Arduino.

Sin embargo, hay configuraciones complejas que son mucho más fáciles de diseñar e implementar en una interfaz de pantalla grande y táctil (límites, alarmas, perfiles de configuración, etc...) y el protocolo se ha ampliado con las tramas 5 (MachineParams) y 6 (AlarmParams) para que se puedan leer y escribir esos parámetros también desde el monitor.

El graficado ya es útil, pero una versión avanzada para manejar los parámetros de la máquina desde el monitor sería muy útil en cuanto a la ergonomía y usabilidad.

Hacerlo en Python o algo que corra también en un PC es deseable para conectarlo a la máquina, en vez de desarrollar un hardware de monitor ad-hoc que resultaría costoso y más difícil de fabricar que echar mano de un viejo portátil o netbook (pensando en soluciones para entornos con pocos recursos).