APOLLO VENTILATOR PROJECT

Este proyecto lo vamos a desarrollar desde el equipo de trabajo de makespace Madrid.
Compartiremos aquí todos nuestros avances dudas y respuestas que puedan aportar algo de valor. 


----------

Actualmente estamos en fase de investigación.

Estamos documentándonos en el foro y entrevistando a algún profesional del sector médico para preguntarle dudas básicas para entender mejor las cosas críticas 

Estamos recabando más información para entender los equipos profesionales completos y los más sencillos y baratos para ver qué puede ser un MVP con posibilidades



Os dejo aquí un resumen, las partes con interrogantes podéis responderlas en comentarios para que podamos actualizar la publicación.

Avances / Descubrimientos / Dudas / Respuestas.

"Eficaz mejor que perfecto"

  • Hay que centrarse en diseñar un respirador válido y simple aunque sea muy limitado para curar a los pacientes con un perfil parecido.

  • Buscar las características fisiológicas del perfil de paciente más común que se espera. Sexo, altura, peso, edad. ¿¿Dónde podríamos conseguir estos datos ???

Dudas sobre las tomas en pared de un hospital

  • Aire comprimido

    • Utilidad - Sirve para algunos equipos de respiración

    • Hay Si / No

    • Valores de salida disponibles

      • Presión ?

      • Caudal ?

      • Hay Manómetro ?

      • Suele haber caídas de presión / caudal - ?

      • Si las hay cómo se compensan - ?

  • Oxígeno

    • Utilidad: sirve para ayudar en la respiración asistida al enfermo

    • Hay Si / No

    • Valores de salida disponibles

      • Presión ?

      • Caudal ?

      • Hay Manómetro?

  • Vacío

    • Utilidad: sirve para absorber el aire contaminado y pasarlo por filtros para eliminar el virus.. 

    • Hay Si / No

    • Valores de salida disponibles

      • Presión ?

      • Caudal ?

      • Hay Manómetro?

Dudas sobre bombonas portátiles de oxígeno:

  • Limitaciones: Duran poco y no pueden considerarse para uso de larga duración.

  • Parámetros a regular

    • Caudal - ?

    • Presión - ?

Equipos comerciales en estudio:

  • Respirador portátil de referencia - Special medic - Mod.SAVE II
  • Investigar idoneidad para la situación actual - pros y contras

  • Parámetros críticos del proceso para un MVP, para un perfil concreto de usuario.

    • Presión de referencia según perfil de usuario.

    • Alarma exceso de presión (dentro del paciente)

    • Alarma falta de presión por escape, fisura del conducto o desenganche del respirador.

    • Específico para Coronavirus

      • Filtro aire de entrada

      • Filtro para aire de salida.

      • Cambio de filtros - Cambio fácil, accesible y limitando la manipulación del operador.

Fuentes:

Lecturas del maquinas del foro.
Conversaciones con sanitarios no especialistas en el tema.

Por eso tenemos dudas que esperamos ir resolviendo  a medida que avancemos



«1

Comentarios

  • Hola Pepe,

    Estas especificaciones de un residente del hospital Johnm Hopkins pueden ayudar.

    https://docs.google.com/document/d/1FNPwrQjB1qW1330s5-S_-VB0vDHajMWKieJRjINCNeE/preview?fbclid=IwAR3ugu1SGMsacwKi6ycAKJFOMduInSO4WVM8rgmC4CgMJY6cKaGBNR14mpM


    Igualmente en este blog de Josh Farkas

    Josh is the creator of PulmCrit.org. He is an associate professor of Pulmonary and Critical Care Medicine at the University of Vermont.

    Menciona que quizá la mejor manera de ayudar es con un respirador de tipo CPAP.
    https://emcrit.org/pulmcrit/cpap-covid/

    No se si hay alguien utilizando esos diseños.

    Finalmente, igual lo más práctico sería seguir el diseño de la reesistencia



    E intentar probarlo en un entorno real y ver como mejorarlo , en lugar de intentar diseñar un respirador de cero.



  • Hello guys! My name is Samuel Marciano.I'm currently living in Brazil.I worked during 4 years at a hospital.As a biomedical techinician.I was assigned to do the maintenance of all medical stuff , lung ventilators included.I'm also doing my major in eletrical and Electronics engineering, so I have a bit of experience in the biomedical area to draw on.I hope I could help you guys iwith it.Feel free to contact me:

    Email:marcianosamuel@gmail.com
    Skype I'd: samuelluiz25
    What's app: +55 19999533461
  • Hola chicos! Me llamo Javi y soy uno de los Makers de MakeSpace Madrid.

    Cómo ya hay bastante gente trabajando en la idea de aplastar balones rees nosotros queremos coger otra aproximación al problema basada en los esquemas de Pancho Cañizo en este mismo foro:

    La idea nos parece sencilla y abordable, una electrovalvula para regular la presión de entrada, sensores de caudal y presión para regular el aire que se entrega,una pizna con un motor para empezar el ciclo de aspiración y un filtro a la salida para recoger los viruses.


    Hoy estamos haciendo esquemas y pseudo-código pero nuestro mayor problema es que no tenemos electrovalvulas y sensores de caudal/presión para ir probando el código.

    Según vayamos avanzando os contamos!

    Let's Make!
    Javi
  • Hola, 
    soy veterinario con 20 años de experiencia en el uso de  equipos sencillos de respiración artificial en anestesia.  Soy de Zaragoza, se que estaís en contacto con ITTAINNOVA.   Me ofrezco para ayuda técnica, pruebas en modelos vivos (perro o cerdo) para comprobar eficacia con garantía éticas y sanitarias en pro de hacer de manera urgente un equipo de respiración artificial seguro para estos momentos.  Puedo dejar mi equipo también para copiar cosas.

    Luis García 685145436

    Gracias
  • Primeras pruebas de valvula/sensor!


  • Hola, dejo la prueba del prototipo para motorizar el inflado y desinflado de la bolsa de un AMBU, la mecanica funciona bien pero necesito hacer pruebas para controlarlo de forma correcta, con un timmer para setear el tiempo de inflado y otro para el tiempo de desinflado.



    Tambien podria ser util la incorporación de un sensor de flujo que funcione como alarma.

    Saludos
  • Hola Pepe,

    Ayer estuve pensando en un prototipo muy similar al vuestro, y qué bonito que esta mañana haya descubierto este foro!
    Por si os sirve de ayuda, pensé en utilizar como insuflador de aire, el motor de los colchones inflables. Mi idea era que ese aire sea dirigido a una "bolsa de mezclado" en la que también hay una entrada de O2, y que la salida de esa bolsa sea mediante un regulador de caudal.  El resto era exactamente igual.
    Los hospitales que yo he visto, en las habitaciones de planta, suelen tener toma de O2 en la pared, así que se podría aprovechar esa toma para conectarla a la "bolsa de mezclado".

    ¡Gracias por llevarlo a cabo!
  • darkjavi. Tengo entendido que no se busca ese efcto. El aparato debe forzar el inflado de los pulmones del paciente y no detectar una succion para abrir la electrovalvula. Corregidme si me equivoco.
  • editado 20 de marzo
    jesconsa dijo:
    darkjavi. Tengo entendido que no se busca ese efcto. El aparato debe forzar el inflado de los pulmones del paciente y no detectar una succion para abrir la electrovalvula. Corregidme si me equivoco.
    Con gusto:
    Fuente: http://web.mit.edu/2.75/projects/DMD_2010_Al_Husseini.pdf

    Primero se intenta detectar la inhalación del paciente y si no sucede se fuerza el ciclo (y posiblemente se dispara una alarma)

    De todas formas, el video de ayer es solo una prueba de sensores/asunciones/posibilidades, no un software de respirador (todavia) :)

    Saludos,
    Javi

  • darkjavi dijo:
    jesconsa dijo:
    darkjavi. Tengo entendido que no se busca ese efcto. El aparato debe forzar el inflado de los pulmones del paciente y no detectar una succion para abrir la electrovalvula. Corregidme si me equivoco.
    Con gusto:
    Fuente: http://web.mit.edu/2.75/projects/DMD_2010_Al_Husseini.pdf

    Primero se intenta detectar la inhalación del paciente y si no sucede se fuerza el ciclo (y posiblemente se dispara una alarma)

    De todas formas, el video de ayer es solo una prueba de sensores/asunciones/posibilidades, no un software de respirador (todavia) :)

    Saludos,
    Javi

    darkjavi
    ¿Sabes si hay más algoritmos para usar en los respiradores?
  • Perdonar el retraso en las actualizaciones. 

    Estamos avanzando lo más rápido que podemos. Pero en las circunstancias actuales es muy complicado. 

    El equipo de Makespace Madrid trabaja totalmente en remoto 24h devorando documentación y especificaciones para apoyar a Darkjavi que es el único miembro que está físicamente prototipando en makespace. 

    Con la cuarentena tenemos los movimientos restringidos y escasa o nula disponibilidad de piezas para avanzar. 

    Lo de ayer fue una prueba de concepto sencilla pero para seguir avanzando necesitamos otros materiales y piezas clave. Estamos elaborando una lista que compartiremos por aquí a la mayor brevedad posible para encontrar los materiales. 

    Por otro lado, hemos conseguido contactar con Pancho Cañizo, médico promotor de la idea con acceso a mejores materiales. 

    Seguiremos informando!


  • Jose_Pizarro Darkjavi, este esquema es más completo y os puede acelerar mucho: https://www.nxp.com/docs/en/application-note/DRM127.pdf

    Gracias por vuestras aportaciones!
  • Hola a todos!

    Actualizamos un poco el estado del proyecto,

    El equipo de MakeSpace Madrid trabaja sin descanso 24/7 en el prototipo de respirador basado en la idea de Pancho Cañizo, todavía no tenemos caudalímetros pero estamos aprovechando a avanzar todas las demás cosas.

    -Electrónica:
    Hay dos diseños de placa casi listos para meter a la fresadora, uno tipo shield para arduino uno y otra versión para arduino nano.

    -Programación:
    Estamos trabajando en un firmware para arduino que gestiona el respirador y otra parte en python para hacer el interfaz de control y gráficas con gtk+numphy+matlab.


    Tanto el firmware como la parte de control de pc todavía están un poco verdes, pero después de haber consumido las toneladas de pdfs e información que hay por este foro empezamos a tener bastante claro lo que tenemos que hacer.


    Video de las pruebas de esta noche:



    Repositorio del proyecto:
    https://github.com/makespacemadrid/ApolloVentilator


    Seguimos!

    Javi
  • Actualización de hoy:


  • editado 24 de marzo
    darkjavi dijo:
    Actualización de hoy:


    Muchas gracias por reportar el  trabajo. Veo que el sensor de presión te funciona bien, ¿no tenéis de los que tienen inlets para meter el tubo directamente?. Habéis probado algún sensor de flujo (de los de presión diferencial) ?

    Parece que ya hay algunos hilos de gente mirando los sensores, pero ¿qué tal vamos con las válvulas?

    Todo el mundo usa solenoides, pero alguien ha probado si esas válvulas controlan bien el flujo o la presión en bucle cerrado.

    Casi todas las válvulas que veo en ventiladores son de este tipo.


    Ánimo.
  • editado 25 de marzo
    De los sensores de flujo me estoy encargando yo, mañana espero poder imprimir el prototipo, si encuentro a alguien en mi ciudad con impresora.
    Revisad el hilo de impresión de  sensores de flujo.
    ..
    Todo el mundo usa solenoides, pero alguien ha probado si esas válvulas controlan bien el flujo o la presión en bucle cerrado.
    En el vídeo observo electroválvulas de lavadora, también he abierto un hilo para poder utilizarlas, pero no como habitualmente se utilizan.
    Es un control complejo y ya paso de explicar las cosas, cuando tenga los resultados os diré si se pueden usar o no para regular los caudales a la frecuencia indicada para crear las gráficas adecuadas de los modos de ventilación.
    No se podrían controlar con un Arduino estas válvulas, como os he dicho,es un control complejo. Yo tengo que usar un micro más potente, mucho más rápido.

    Trabajar en tiempo real con Arduino es un poco temerario, los errores debidos al tiempo os van a complicar bastante la vida.

    Pasad a las Bluepill, os lo recomiendo, que no os pase como a los desarrolladores de los respiradores AMBU.

    Os puedo dar soporte en cuanto a la programación (algo de tiempo sacaría) y no tendríais problemas en cuanto a la velocidad y al procesamiento (se trabaja con 32 bits).

    Buscad mi hilo en donde explico como empezar a trabajar con las Bluepill usando el mismo entorno de desarrollo software del Arduino.
    Muchas de las librerías son 100% compatibles.
    Los Serial.print se utilizan igual (tanto para el adaptador USB "interno" como para las dos UARTS adicionales que tiene).
    Serial1.print y Serial2.print. Además de poder usar PWM de 32 bits de resolución, 10 canales ADCs de 12 bits y velocidadades de muestreo de 1us, y con pines tolerantes a 5V.
    La librería de Roger Clark stm32duino es la apropiada, ya que la de ST no tiene todas las caracteristicas que he mencionado.
    NewLiquidCrystal funciona igual, los 2 puertos I2C permiten conectar a mayores velocidades, 400 Khz y superiores al Mhz.
    Y también tiene puertos SPI, aunque para esto en principio no hay nada qe los requiera.

    Adjunto también el esquema en pdf.
  • editado 25 de marzo
    darkjavi dijo:
    ..
    Tanto el firmware como la parte de control de pc todavía están un poco verdes, pero después de haber consumido las toneladas de pdfs e información que hay por este foro empezamos a tener bastante claro lo que tenemos que hacer.
    ..
    Os animo a que continuéis, pero revisad todos y cada uno de mis hilos.
    https://foro.coronavirusmakers.org/index.php?p=/profile/discussions/Jose_Pizarro

    Intenté ayudar a los creadores de respiradores AMBU y ninguno me tuvo en cuenta, ni me leyó.

    Ahora os intento ayudar a vosotros, no es sencillo, hay que conseguir un control bastante preciso y rápido.

    Al igual que les dije a los demás que aumentaran de tamaño de motor a un Nema 34, os recomiendo a vosotros que aumentéis a un microcontrolador más potente también.

    Yo seguiré aquí ayudando en lo que pueda, termino con los sensores de flujo y me pongo con las electroválvulas de lavadora.

    La App de monitoriazación Iot está bastante avanzada, la está realizando también otro colaborador siguiendo las indicaciones de otro de mis hilos (con un broker MQTT mosquitto).

    Al menos mirad los títulos de mis hilos.
    Aunque no sea la forma en la que lo hagáis vosotros, algo os podrá aportar.

    Estoy intentando adelantarme a todos los problemas, si revisáis las fechas, no suelo equivocarme, las cosas pasan como voy indicando días antes de que pasen.

    Saludos
    Jose_Pizarro
  • editado 25 de marzo
    pepe_sb1 dijo:
    Este proyecto lo vamos a desarrollar desde el equipo de trabajo de makespace Madrid.
    Compartiremos aquí todos nuestros avances dudas y respuestas que puedan aportar algo de valor. 


    ----------

    Actualmente estamos en fase de investigación.

    Estamos documentándonos en el foro y entrevistando a algún profesional del sector médico para preguntarle dudas básicas para entender mejor las cosas críticas 

    Estamos recabando más información para entender los equipos profesionales completos y los más sencillos y baratos para ver qué puede ser un MVP con posibilidades

    Buenas noches pepe_sb1

    Me parece bien que recabes información del foro, pero al igual que otros colaboradores le dedicamos gran parte de nuestro tiempo a publicar la información de la que vamos disponiendo para que todo el mundo pueda aprovecharla, sería igual de "bueno" que los que recaben información también la aporten.

    No es porque la necesitemos nosotros, sino porque la puede necesitar cualquier otro que también esté buscando esa información. Aunque esa información no sea para utilizarla en vuestro proyecto.

    BME280
    Por ejemplo, podíais haber puesto que usáis los barómetros de Bosch BMP180 / BME280 como sensores de presión.
    El publicar en este foro la información de la que disponéis hasta os puede beneficiar a vosotros.
    Ya te puedo decir que ese sensor lo podéis desechar, no vale.
    ¡Más claro no puedo ser!

    Ahora cualquier diseñador sabrá que esos sensores de presión no se deben de utilizar.

    He abierto varios hilos para que la gente pueda colaborar aportando información relevante, pero la mayoría de gente es "egoísta" y "orgullosa", y una vez obtiene lo que estaba buscando se olvida de aportar (aunque no le cueste nada).

    A menos que decida lo contrario, esta misma noche voy a publicar el diseño de un sensor de flujo que se podrá imprimir, algo que hago por gusto, por conciencia, por los que están sufriendo y para que otros puedan también avanzar.

    Intento adelantarme en la medida de lo posible a lo que se va a necesitar, no para presentar una placa por la televisión, como hacen otros, y no me estoy refiriendo a vosotros, sino para ganar alguna batalla a esta enfermedad.

    Posiblemente en un par de días tenga funcionando las electroválvulas de lavadora correctamente, y haya millones disponibles para todo el mundo.

    Pensarás, controlar una electroválvula de lavadora es fácil,.. pues ya verás que no, al menos no como se debe de controlar para cumplir con lo que se necesita.
    Por ejemplo, picos de flujo de 200l/min sin sobrepasar las presiones definidas y siguiendo las curvas de los modos de ventilación no se podrán conseguir con un control PWM de un arduino nano sin tener errores considerables.

    Vamos a colaborar todos y agradecería que dejarais de publicitarse tan abiertamente, porque lo importante no es colgarse la medalla, sino salvar vidas.
  • editado 25 de marzo
    NO usar los BARÓMETROS como sensores de presión:
    Ningún barómetro es válido, ni éstos de Bosch BME280, BME180, BMP180, ni otros.

    ¿Por qué?
    Voy a poner como ejemplo el BME280.
    Tiene un rango de medición de 300 hPa a 1100hPa.

    Lo primero, es un sensor de presión absoluta, por ser un barómetro.
    No mide la presión relativa como lo hacen los sensores "diferenciales" o los "gauge".
    Estudiad un poco los tipos de sensores fabricados en silicio.

    Todos los profesionales de este tipo de maquinaria respiratoria desaconsejan el uso de sensores de presión absoluta, y es porque pequeños cambios de presión atmosférica producirían grandes errores en las mediciones.
    Y si cambiamos la altura donde se encuentra el sensor, ya sea subiendo o bajando montañas, la descalibración es enorme.

    Lo segundo, el rango de medida que se va a utilizar está muy lejos del rango de medición del barómetro.
    Para no liarnos, voy a pasar la unidad de medida del barómetro a mbar.

    300 hPa a 1100hPa ==> 300mbar a 1100mbar (de presión absoluta).

    Suponiendo que estamos sobre el nivel del mar y hay 1 bar de presión (1 atm):
    El sensor mediría desde 1000 hasta 1100 mbar.

    Es decir, a nivel del mar no podríamos superar 100 mbar en las mediciones.
    Vale, esto puede considerarse correcto, estamos dentro del límite (que se pueda mediar hasta 60mbar, para cumplir las especificaciones).

    Pero, qué pasa con la precisión.
    Este sensor tiene una precisión del +-1.0hPa en el rango de 300hPA a 1100hPa.
    En mbar sería +-1.0mbar en el rango de 300mbar a 1100mbar.
    Como nos encontramos sobre el nivel del mar:
    +-1.0 mbar en el rango de medición de 0mbar a 100mbar.

    +-1 mbar no parece mucho.
    Recordemos el rango de presiones del doctor Pancho_Cañizo:
    Rango de presiones: Entre 5 y 40 mmHg ==> 6.58 a 52.6mbar

    Cuando se ajuste la presión al mínimo se estaría cometiendo un error de precisión de +-1.0 mbar en un ajuste de 6.58mbar, es decir, estaríamos en el rango real de 5.58 a 7.58mbar (+-15% aprox.).

    A ese error de precisión que estaría en el rango de +-15%, habría que añadirle el error debido a cambios de presión atmosférica, por cambios de altura respecto al nivel del mar, por el proceso de soldadura de cada chip en concreto y por el envejecimiento por año transcurrido (+-1hPa = +-15% adicional).

    La precisión final de estos sensores al final sería muy baja, obligaría a estar recalibrándolos , creando algoritmos de cancelación de offset y usando otros barómetros al mismo tiempo.

    Todo lo indicado son métodos que se pueden utilizar para disminuir esos errores de precisión, pero a menos que sea la última opción, no interesa su uso.

    Es preferible invertir unos pocos euros más en un sensor de presión diferencial o del tipo "gauge" y no estar con estos sensores de céntimos realizando algoritmos de cancelación de offset.

  • darkjavi dijo:
    Hola a todos!

    Actualizamos un poco el estado del proyecto,

    El equipo de MakeSpace Madrid trabaja sin descanso 24/7 en el prototipo de respirador basado en la idea de Pancho Cañizo, todavía no tenemos caudalímetros pero estamos aprovechando a avanzar todas las demás cosas.

    -Electrónica:
    Hay dos diseños de placa casi listos para meter a la fresadora, uno tipo shield para arduino uno y otra versión para arduino nano.

    -Programación:
    Estamos trabajando en un firmware para arduino que gestiona el respirador y otra parte en python para hacer el interfaz de control y gráficas con gtk+numphy+matlab.


    Tanto el firmware como la parte de control de pc todavía están un poco verdes, pero después de haber consumido las toneladas de pdfs e información que hay por este foro empezamos a tener bastante claro lo que tenemos que hacer.


    Video de las pruebas de esta noche:



    Repositorio del proyecto:
    https://github.com/makespacemadrid/ApolloVentilator


    Seguimos!

    Javi
    Hola Javi.

    Recomiendo encarecidamente que le pongas taladros de fijación sin metalizar al PCB. No lo vas a poder integrar correctamente si no. Además para las pruebas van a estar rozando los pines de los componentes en todas las superficies. 

    Si queréis una segunda opinión puedo ayudaros.

    Saludos.
  • De los sensores de flujo me estoy encargando yo, mañana espero poder imprimir el prototipo, si encuentro a alguien en mi ciudad con impresora.
    Revisad el hilo de impresión de  sensores de flujo.
    ..
    Todo el mundo usa solenoides, pero alguien ha probado si esas válvulas controlan bien el flujo o la presión en bucle cerrado.
    En el vídeo observo electroválvulas de lavadora, también he abierto un hilo para poder utilizarlas, pero no como habitualmente se utilizan.
    Es un control complejo y ya paso de explicar las cosas, cuando tenga los resultados os diré si se pueden usar o no para regular los caudales a la frecuencia indicada para crear las gráficas adecuadas de los modos de ventilación.
    No se podrían controlar con un Arduino estas válvulas, como os he dicho,es un control complejo. Yo tengo que usar un micro más potente, mucho más rápido.

    Trabajar en tiempo real con Arduino es un poco temerario, los errores debidos al tiempo os van a complicar bastante la vida.

    Pasad a las Bluepill, os lo recomiendo, que no os pase como a los desarrolladores de los respiradores AMBU.

    Os puedo dar soporte en cuanto a la programación (algo de tiempo sacaría) y no tendríais problemas en cuanto a la velocidad y al procesamiento (se trabaja con 32 bits).

    Buscad mi hilo en donde explico como empezar a trabajar con las Bluepill usando el mismo entorno de desarrollo software del Arduino.
    Muchas de las librerías son 100% compatibles.
    Los Serial.print se utilizan igual (tanto para el adaptador USB "interno" como para las dos UARTS adicionales que tiene).
    Serial1.print y Serial2.print. Además de poder usar PWM de 32 bits de resolución, 10 canales ADCs de 12 bits y velocidadades de muestreo de 1us, y con pines tolerantes a 5V.
    La librería de Roger Clark stm32duino es la apropiada, ya que la de ST no tiene todas las caracteristicas que he mencionado.
    NewLiquidCrystal funciona igual, los 2 puertos I2C permiten conectar a mayores velocidades, 400 Khz y superiores al Mhz.
    Y también tiene puertos SPI, aunque para esto en principio no hay nada qe los requiera.

    Adjunto también el esquema en pdf.
    Jose_Pizarro,
    Muchas gracias por las aportaciones, estamos muy interesados en toda la experiencia que nos puedas aportar, y en compartir la poca que tenemos.

    Especialmente estoy interesado en la experiencia con las electroválvulas, pues justo estoy abordando el tema. Hace un par de noches hice unas pruebas con PWM y no hay manera, ahora estoy preparando el código para otras dos estrategias para probarlas:

    -Idea 1(en pruebas hoy): poner la válvula a oscilar a 10Hz y regular el tiempo que está abajo(cómo un pwm pero con los ciclos de trabajo más largos)

    //Valve cycle for 10hz 100%
    //|open  |  opened   |   close|
    //|25ms |    50ms    | 25ms  |
    //|--------|--------------|--------|

    //Valve cycle for 10hz 50%
    //|open    opened   |   close |
    //|25ms |    25ms   | 25ms   |
    //|--------|------------|------------|

    -Idea 2,establecer un ritmo de 'pulsaciones/martilleo' de la válvula(ligeramente distinto a la aproximación anterior) y conectar la válvula a un bucle pid regulado por el sensor de presión.

    Si pudiéramos hablar un rato me encantaría comentar las estrategias para las válvulas.

    En el taller tenemos varias 3D, si necesitas hacer alguna prueba de impresión estaríamos encantados de ayudar.

    En cuanto a los materiales, somos conscientes de que nuestro prototipo está hecho con 'chatarra' del taller, mientras conseguimos localizar algo mejor esto nos permite ir validando soluciones.

    En cuanto a electrónica y programación estamos intentando trabajar de manera portable/sobrecargable, si hay que cambiar el bme280 por el AWM720P1 pues sobrecargamos la clase del sensor y lo implementamos. Si conseguimos acceso a las SMT cambiamos el circuito de la pcb y cargamos el código remapeando pines(voy a consultar con el diseñador de electrónica a ver si puede añadir unos footprints compatibles con el smt).


    Uno de los ejes en los que nos estamos moviendo es que con todos los recursos que hay disponibles para mejoras y fabricación nuestra labor no es dar con la solución final si no proveer de un blueprint viable y testado para que los demás recursos que hay disponibles  puedan seguir avanzandolo.

    Pedimos disculpas si nuestra ilusión genera ruido, sé que estos días el foro esta lleno de ruido y 'polinizadores de threads', en nuestra defensa solo puedo decir que intentamos mantener una 'buena' relación signal/noise, (repito, se que hay mucho ruido, pero nosotros solo hemos mandado 2 mensajes en total al hilo de Pancho y en línea con su prototipo)

    No tenemos afán ninguno más que el de usar nuestros superpoderes para el bien :)

    Lets Make!
    Javi
  • También he leido por ahi monitorización mqtt... nos parece genial!
    aún está lejos en el roadmap pero empezamos a pensar en posibles sistemas de monitorización del parque de respiradores. Estábamos barruntando la idea de hacer que el respirador haga post de los datos a un influx/mongodb y después usar grafana para la gestión de alarmas centralizada, pero de momento estamos lejos de abordarlo.
  • Os dejo la actualización de los materiales que recibimos ayer, tenemos mapleson, globo de pruebas y un nuevo integrante del equipo, nuestro amigo Wilson Alveolo.

    https://www.youtube.com/watch?v=blUf6uq4Oqc
  • editado 25 de marzo

    BME280
    Por ejemplo, podíais haber puesto que usáis los barómetros de Bosch BMP180 / BME280 como sensores de presión.
    El publicar en este foro la información de la que disponéis hasta os puede beneficiar a vosotros.
    Ya te puedo decir que ese sensor lo podéis desechar, no vale.
    ¡Más claro no puedo ser!

    Ahora cualquier diseñador sabrá que esos sensores de presión no se deben de utilizar.

    He abierto varios hilos para que la gente pueda colaborar aportando información relevante, pero la mayoría de gente es "egoísta" y "orgullosa", y una vez obtiene lo que estaba buscando se olvida de aportar (aunque no le cueste nada).

    A menos que decida lo contrario, esta misma noche voy a publicar el diseño de un sensor de flujo que se podrá imprimir, algo que hago por gusto, por conciencia, por los que están sufriendo y para que otros puedan también avanzar.

    Intento adelantarme en la medida de lo posible a lo que se va a necesitar, no para presentar una placa por la televisión, como hacen otros, y no me estoy refiriendo a vosotros, sino para ganar alguna batalla a esta enfermedad.

    Posiblemente en un par de días tenga funcionando las electroválvulas de lavadora correctamente, y haya millones disponibles para todo el mundo.

    Pensarás, controlar una electroválvula de lavadora es fácil,.. pues ya verás que no, al menos no como se debe de controlar para cumplir con lo que se necesita.
    Por ejemplo, picos de flujo de 200l/min sin sobrepasar las presiones definidas y siguiendo las curvas de los modos de ventilación no se podrán conseguir con un control PWM de un arduino nano sin tener errores considerables.

    Vamos a colaborar todos y agradecería que dejarais de publicitarse tan abiertamente, porque lo importante no es colgarse la medalla, sino salvar vidas.

    La eleccion de los BME280 es porque es lo que teniamos disponible.  El valor de este proyecto consiste en prototipar una solucion para los proximos dias o una-dos semanas hasta cuando lleguen los productos buenos industriales que segun las noticias se estan fabricando a tope en las empresas de hardware medico (y otras...).. segun entiendo. 

    Mientras tanto, claramente se necesitan dos BME280, uno para medir la presion estatica atmosferica y otro en el interior del tubo de aspiracion, es algo que estaba asumido.  En este uso la precision de este sensor que importa es la de los 0.12 hPa porque medir presion absoluta no nos interesa.  El firmware tiene que, si o si, medir la diferencia entre lo que dan los dos sensores al inicio del funcionamiento con el sistema en reposo, y hacer la medidas posteriores siempre en relacion a este valor (el cual tambien se tiene que actualizar segun va variando la presion exterior filtrada por un filtro de paso bajo lento).

    Personalmente en mi experiencia con los BME280 y BMP085, el BME280 bien filtrado da incluso bastante mas precision de 0.12 hPa (que corresponderia a 1m de variacion de altitud de presion), pudiendo estabilizar una aeronave con unos 30cm de precision en altitud.

    Lo que hay que pensar es como posicionar el sensor interior relativo al flujo de gas porque estando en un tubo lateral estara afectado por el efecto venturi, el movimiento del gas en el tubo principal va a producir depresion en el tubo lateral que va a falsificar la medida de la presion total.

    La eleccion de arduinos aparte de la disponibilidad tambien tiene la ventaja de que son en mi experiencia mas resistentes a fallos electricos que las placas que integran STMs y otros ARMs y es algo que valoro para proyectos de prototipado rapido.
  • Estuve leyendo el foro y me ha entrado una duda. Soy dentista, pero con bastante relación con los anestesistas. Hasta donde yo sé, los respiradores se ponen a pacientes intubados. Los pacientes intubados están sedados y miorelajados para evitar entre otras cosas el reflejo de tos y arcada que imposibilitaría mantener el tubo en su sitio.

    La principal implicación es que el paciente NUNCA VA A RESPIRAR POR SI SOLO. De hecho, el proceso más crítico es insuflar la cantidad de aire adecuada para no sobrepasar la presión tolerada por el pulmón (si se excede se puede llegar a romper, pensar en un globo conectado a un compresor de coche).

    Por lo demás me parece un proyecto interesante. En lo que pueda ayudar lo intento.
  • editado 25 de marzo
    ¿Alguien sabe como funciona el ciclo de expiración?
    Si baja la presión de 16cmH2O a por ejemplo, la atmosférica o 5cmH2O con PEEK, ¿El paciente exhala el aire de forma espontánea por la elasticidad o hay q ayudar con depresión?
    Gracias!!
  • Dejo por aqui un video de cómo son los tubos y las conexiones del intubado/mapleson.

  • editado 27 de marzo
    balrog dijo:
    ..
    La eleccion de arduinos aparte de la disponibilidad tambien tiene la ventaja de que son en mi experiencia mas resistentes a fallos electricos que las placas que integran STMs y otros ARMs y es algo que valoro para proyectos de prototipado rapido.
    Creo haberte entendido.

    Si tu experiencia, está limitada a Arduinos, tu capacidad de desarrollo también está limitada a estas placas.

    No digas que las placas con STM o ARM son menos resistentes a fallos eléctricos, porque no es así.
    Por cierto los STM32 son ARM y hay placas Arduino que también son ARM, así que documéntate para no decir incongruencias.

    https://www.st.com/resource/en/datasheet/stm32f103c8.pdf
    En las páginas 58 y 59 indican los test EMS, ESD y EMI a los que han sometido al circuito integrado, con indicación de las clases y las hojas de aplicación.

    http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf
    No indican ningún tipo de test de los mencionados anteriormente.

    Y con esto no digo que los Atmega328 no hayan pasado test de EMC, sino que el fabricante no los ha documentado en sus hojas de características.

    Son los diseños incorrectos causados por diseñadores inexpertos los que provocan que las placas fallen.

    Si quieres desacreditar a un microcontrolador porque no se adapta a lo que te viene bien a ti, hazlo con argumentos, no con comentarios basados en tu experiencia, que pueda que sea menor a la de otros diseñadores electrónicos profesionales con mas experiencia que la tuya.

    En cuanto a la disponibilidad de las placas, ha sido tanta la demanda de las Bluepill que debido a la masiva producción de ésta, su coste ha bajado tanto que está por debajo que el coste de las placas Arduino.

    Habrá suficientes microcontroladores para abastecer todos los respiradores que vayan a hacer falta.

    Para envío inmediato (hoy 27/02/2020):
    2262 unidades
    5373 unidades
    Dos distribuidores cualquiera que en 72 horas me facilitarían mas de 7500 microcontroladores.
    Y con el resto de modelos compatibles el número de unidades sería muchísimo mayor.

    Que cada cual le dedique su tiempo a lo que quiera, yo no voy a decirle a nadie lo que puede o no puede hacer.

    Respeto que la gente no le haga caso a mis recomendaciones.

    Pero lo que no acepto es que se hagan afirmaciones que confundan a la gente con información incorrecta.
  • Hola Jose, he trabajado un poco con STM32 y con algunos ARMs sin MMU mas.

    Claro, existen Arduinos con un ARM (o varios en una placa) pero estabamos hablando de los Pro Mini y nano que son atmegas.  Y mi experiencia es que en un proyecto de prototipado rapido que no requiere mucha computacion (ver mas abajo) estos que van a 5V son mas adecuados porque pueden aguantar ciertos picos de voltaje y corriente, creo recordar que Atmel provee hasta versiones resistentes a la radiacion para usos espaciales.  Tampoco es un PLC pero para ciertas cosas puedes permitirte hacer un diseño rapido sin poner diodos de proteccion en todos los pines y a esto me refiero con prototipado rapido... claro que un circuito bueno y completo, basado en simulaciones y Application Notes del fabricante, va a funcionar con cualquier micro y con cualquier placa.  Hay diferencia entre desarrollo industrial y desarrollo rapido para una situacion de emergencia, hay que reconocerla.  No se trata de inexperiencia sino de crear algo antes de que deje de tener utilidad.

    No tengo experiencia con la Bluepill concretamente, no se si tiene integrados los diodos de proteccion, no estaba hablando de la Bluepill.

    Por otra parte noto que muchos, no solo tu, se equivocan en cuanto a la capacidad de procesamiento de las atmegas corriendo a 16MHz.  No son micros que terminan bucles infinitos en 1 segundo ;)  no puedes estar desperdiciando ciclos -- p.e. leer y escribir al puerto serie sin usar interrupciones -- pero dan para bastante mas de lo que necesitamos aqui, cuando escribes codigo de calidad.  En ciertos dispositivos estos micros leen sensores y sobre los datos aplican matematica bastante complicada (filtros de Kalman) sobre quaterniones, es decir matrices 4x4 de coma flotante a 100Hz, a la vez comunicando con el GPS en el puerto serie, respondiendo a comandos del usuario y corriendo multiples bucles PID para controlar motores.  En este proyecto no se va a aprovechar ni 0.01 de esta capacidad.

    En el Makespace hemos hablado en algun momento de la eleccion del micro y dado que el entorno de programacion (platform.io) soporta bastantes placas de desarrollo populares, vamos a seguir con AVR hasta el primer momento en el que se quede corto ya que cambiar de placa va a ser un cambio facil, pero de momento innecesario.
Accede o Regístrate para comentar.