Saque las cosas de gestion
parent
26a3e5b3fa
commit
f23b2df2dd
@ -1,21 +0,0 @@
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"c07561cc0537046a","type":"text","text":"Radar UWB","x":-125,"y":-30,"width":250,"height":60,"color":"2"},
|
||||
{"id":"d4c4c272a9d4ca56","type":"text","text":"Entrenamiento de modelo","x":990,"y":320,"width":250,"height":60,"color":"4"},
|
||||
{"id":"7d392813c4b7533b","type":"text","text":"Algoritmo de detección de anomalias","x":790,"y":-30,"width":250,"height":60,"color":"2"},
|
||||
{"id":"ff56c352381141dd","type":"text","text":"Procesamiento de la señal de radar","x":348,"y":-30,"width":250,"height":60,"color":"2"},
|
||||
{"id":"b75bef0e275989cc","type":"file","file":"Esquemas/Esquemas Secundarios/Procesmiento de la señal.canvas","x":246,"y":150,"width":455,"height":220,"color":"4"},
|
||||
{"id":"3e8c8f4732482042","type":"text","text":"Obtención de la base de datos","x":740,"y":400,"width":250,"height":60,"color":"4"},
|
||||
{"id":"446d44a0dbe9d8e4","type":"text","text":"Selección del modelo de clasificación","x":800,"y":215,"width":250,"height":60,"color":"4"},
|
||||
{"id":"0b5a7eb55d98262e","type":"text","text":"Este radar ya esta diseñado solo hay que ver las características que tiene","x":-161,"y":200,"width":322,"height":91,"color":"4"}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"17f70b2bd7f69300","fromNode":"c07561cc0537046a","fromSide":"right","toNode":"ff56c352381141dd","toSide":"left","color":"2"},
|
||||
{"id":"4163b31f559aa450","fromNode":"ff56c352381141dd","fromSide":"right","toNode":"7d392813c4b7533b","toSide":"left","color":"2"},
|
||||
{"id":"fdf48b6fe1936ade","fromNode":"c07561cc0537046a","fromSide":"bottom","toNode":"0b5a7eb55d98262e","toSide":"top","color":"4"},
|
||||
{"id":"59059acdde4b289a","fromNode":"ff56c352381141dd","fromSide":"bottom","toNode":"b75bef0e275989cc","toSide":"top","color":"4"},
|
||||
{"id":"b898b05b7df1e389","fromNode":"7d392813c4b7533b","fromSide":"bottom","toNode":"446d44a0dbe9d8e4","toSide":"top","color":"4"},
|
||||
{"id":"1f43a629450ac93b","fromNode":"7d392813c4b7533b","fromSide":"bottom","toNode":"d4c4c272a9d4ca56","toSide":"top","color":"4"},
|
||||
{"id":"273dbdd1294f9079","fromNode":"7d392813c4b7533b","fromSide":"bottom","toNode":"3e8c8f4732482042","toSide":"top","color":"4"}
|
||||
]
|
||||
}
|
||||
@ -1,20 +0,0 @@
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"a8ad8a2197a28a38","type":"text","text":"Entrada de señal vital","x":-300,"y":-40,"width":250,"height":60,"color":"3"},
|
||||
{"id":"d70ab2aa8277b865","type":"text","text":"Detección de movimientos","x":290,"y":-220,"width":250,"height":60,"color":"3"},
|
||||
{"id":"fec240b29c3c8595","type":"text","text":"Lidiar con el ruido","x":290,"y":160,"width":250,"height":60,"color":"3"},
|
||||
{"id":"fb3af70300287327","x":720,"y":-134,"width":250,"height":60,"color":"3","type":"text","text":"Salida de datos pre-procesados"},
|
||||
{"id":"238c18dd2bc4890e","type":"text","text":"Lidiar con el clutter","x":60,"y":-40,"width":250,"height":60,"color":"3"}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"42a76d05eaeb34ed","fromNode":"a8ad8a2197a28a38","fromSide":"right","toNode":"d70ab2aa8277b865","toSide":"left","color":"3"},
|
||||
{"id":"b014f65ec2a6e6ea","fromNode":"a8ad8a2197a28a38","fromSide":"right","toNode":"238c18dd2bc4890e","toSide":"left","color":"3"},
|
||||
{"id":"19e15f8751bd084d","fromNode":"a8ad8a2197a28a38","fromSide":"right","toNode":"fec240b29c3c8595","toSide":"left","color":"3"},
|
||||
{"id":"defd3f1ad1a35e6b","fromNode":"238c18dd2bc4890e","fromSide":"bottom","toNode":"fec240b29c3c8595","toSide":"top","fromEnd":"arrow","label":"Interconección"},
|
||||
{"id":"c3c69080c7150819","fromNode":"d70ab2aa8277b865","fromSide":"bottom","toNode":"238c18dd2bc4890e","toSide":"top","fromEnd":"arrow","label":"Interconexión"},
|
||||
{"id":"31c46082db0787d3","fromNode":"d70ab2aa8277b865","fromSide":"bottom","toNode":"fec240b29c3c8595","toSide":"top","fromEnd":"arrow","label":"Interconección"},
|
||||
{"id":"dfc75d78cb1f20ce","fromNode":"238c18dd2bc4890e","fromSide":"right","toNode":"fb3af70300287327","toSide":"left","color":"3"},
|
||||
{"id":"c37fcbce45ab94ed","fromNode":"d70ab2aa8277b865","fromSide":"right","toNode":"fb3af70300287327","toSide":"left","color":"3"},
|
||||
{"id":"64bedf6f005a7800","fromNode":"fec240b29c3c8595","fromSide":"right","toNode":"fb3af70300287327","toSide":"left","color":"3"}
|
||||
]
|
||||
}
|
||||
@ -1,23 +0,0 @@
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"94f872727f48c28d","type":"text","text":"Entrada de la señal de radar","x":-125,"y":-30,"width":250,"height":60,"color":"4"},
|
||||
{"id":"574baf0984e0b616","type":"text","text":"Procesamiento de la señal de radar","x":232,"y":-32,"width":250,"height":60,"color":"4"},
|
||||
{"id":"f619453483115258","type":"text","text":"Salida de datos","x":1260,"y":29,"width":250,"height":60,"color":"4"},
|
||||
{"id":"9d93f7f11ecd0438","type":"text","text":"Hay que definir el método del análisis espectral","x":950,"y":131,"width":250,"height":60,"color":"3"},
|
||||
{"id":"2d1402e486db50eb","type":"text","text":"Pre-procesamiento de la señal vital","x":580,"y":-34,"width":250,"height":65,"color":"4"},
|
||||
{"id":"5612c667a96d8964","type":"text","text":"Análisis espectral de la señal vital","x":920,"y":-37,"width":250,"height":70,"color":"4"},
|
||||
{"id":"c30a2f63f8bafc67","type":"text","text":"Demodulación de la señal de radar","x":107,"y":200,"width":250,"height":60,"color":"3"},
|
||||
{"id":"6c0305e5412426b9","type":"text","text":"Detector de retardo de la señal de radar","x":330,"y":320,"width":250,"height":60,"color":"3"},
|
||||
{"id":"4363549547e7f82b","x":683,"y":248,"width":392,"height":265,"color":"3","type":"file","file":"Esquemas/Esquemas Secundarios/Pre-procesamiento de la señal vital.canvas"}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"35fc82cef4dc9bd0","fromNode":"94f872727f48c28d","fromSide":"right","toNode":"574baf0984e0b616","toSide":"left","color":"4"},
|
||||
{"id":"e1c07b5209719b70","fromNode":"574baf0984e0b616","fromSide":"right","toNode":"2d1402e486db50eb","toSide":"left","color":"4"},
|
||||
{"id":"3ed5ba1a6b586f1e","fromNode":"2d1402e486db50eb","fromSide":"right","toNode":"5612c667a96d8964","toSide":"left","color":"4"},
|
||||
{"id":"09366889c66d6c63","fromNode":"5612c667a96d8964","fromSide":"right","toNode":"f619453483115258","toSide":"left","color":"4"},
|
||||
{"id":"5a813fdb92511481","fromNode":"5612c667a96d8964","fromSide":"bottom","toNode":"9d93f7f11ecd0438","toSide":"top","color":"3"},
|
||||
{"id":"065a05e2bd4161dc","fromNode":"574baf0984e0b616","fromSide":"bottom","toNode":"c30a2f63f8bafc67","toSide":"top","color":"3"},
|
||||
{"id":"281e64f3e163b384","fromNode":"574baf0984e0b616","fromSide":"bottom","toNode":"6c0305e5412426b9","toSide":"top","color":"3"},
|
||||
{"id":"f52553134c9ac803","fromNode":"2d1402e486db50eb","fromSide":"bottom","toNode":"4363549547e7f82b","toSide":"top","color":"3"}
|
||||
]
|
||||
}
|
||||
@ -1,45 +0,0 @@
|
||||
# Análisis FODA del Proyecto: Detección de Anomalías Cardiorrespiratorias con Radares UWB
|
||||
|
||||
### 0.1. Análisis FODA
|
||||
|
||||
A continuación se desarrolla un análisis de fortalezas, oportunidades, debilidades y amenazas vinculadas al desarrollo y despliegue del proyecto.
|
||||
|
||||
**Fortalezas**
|
||||
|
||||
- **Vínculo con un instituto de investigación especializado**: Existe un contacto activo con una institución que investiga las tecnologías involucradas, lo que aporta respaldo técnico y acceso a conocimiento actualizado.
|
||||
- **Base técnica sólida del equipo**: El equipo cuenta con formación en electrónica, software y procesamiento de señales, lo que permite abordar internamente los principales desafíos tecnológicos.
|
||||
- **Bajo costo del diseño de hardware**: El diseño inicial proyecta un costo reducido para los componentes, permitiendo desarrollar el MVP con recursos moderados.
|
||||
- **Escalabilidad del producto**: La solución es adaptable para nuevas funcionalidades, como la detección de distintas patologías, lo que habilita la expansión a otros nichos de mercado en el futuro.
|
||||
- **Control de desarrollo in-house**: Al ser un desarrollo propio, se puede iterar rápidamente sin depender de terceros o licencias de software/hardware externas.
|
||||
- **Alta diferenciación funcional**: El enfoque no invasivo para monitoreo vital en bebés es único dentro del segmento doméstico, lo que otorga una ventaja clara frente a otros productos.
|
||||
|
||||
**Oportunidades**
|
||||
|
||||
- **Tecnología UWB segura y aprobada**: El uso de radar UWB ya está regulado y validado para entornos humanos, facilitando su homologación médica.
|
||||
- **Falta de dispositivos similares en el mercado**: Actualmente no existen productos que monitoreen ritmo respiratorio y cardíaco en bebés de forma no invasiva, lo que representa una oportunidad de innovación.
|
||||
- **Tendencia en crecimiento del interés por UWB**: La tecnología está en expansión en distintas aplicaciones, y su adopción genera un entorno favorable para el desarrollo de productos basados en ella.
|
||||
- **Envejecimiento de otras tecnologías en uso**: Muchos monitores actuales se basan en sensores de contacto o bandas físicas, tecnologías que presentan limitaciones frente a la propuesta UWB.
|
||||
- **Potencial interés de organismos de salud**: Si se demuestra precisión y utilidad clínica, el producto podría interesar a hospitales, neonatologías y programas de salud pública.
|
||||
- **Acceso a subsidios y programas de innovación**: El carácter tecnológico y biomédico del proyecto podría hacerlo elegible para fondos públicos o privados de I+D.
|
||||
|
||||
**Debilidades**
|
||||
|
||||
- **Falta de perfiles técnicos clave**: El equipo actual no cuenta con especialistas en desarrollo de servidores, aplicaciones móviles ni asesoramiento médico.
|
||||
- **Ausencia de colaboración con equipos médicos**: No existen vínculos establecidos con instituciones o profesionales médicos que puedan validar o mejorar el enfoque clínico del producto.
|
||||
- **Poca experiencia en desarrollo de productos**: El equipo no cuenta con antecedentes en el diseño, testeo y despliegue de prototipos o MVPs para el mercado.
|
||||
- **Falta de financiación asegurada**: Actualmente no se dispone de los fondos necesarios para llevar a cabo el desarrollo completo del sistema.
|
||||
- **Proceso regulatorio incierto**: Aunque la tecnología UWB esté aprobada, la certificación del dispositivo completo puede requerir conocimientos y procesos complejos.
|
||||
- **Limitada experiencia en diseño industrial**: El diseño físico del gabinete puede presentar dificultades si no se cuenta con especialistas en producto o ergonomía.
|
||||
|
||||
**Amenazas**
|
||||
|
||||
- **Competencia indirecta en el mercado de monitoreo infantil**: Existen múltiples productos que, aunque no miden los mismos parámetros, podrían ser percibidos como soluciones alternativas.
|
||||
- **Condiciones económicas desfavorables**: El producto podría ser considerado de nicho o de lujo, lo que limitaría su adopción en contextos de baja capacidad adquisitiva o crisis económica.
|
||||
- **Barrera regulatoria y legal**: El proceso de homologación para uso médico puede extenderse, complejizarse o implicar altos costos.
|
||||
- **Aceleración de competidores tecnológicos**: Empresas con mayor capital podrían lanzar productos similares más rápido, con más marketing o distribución.
|
||||
- **Preocupaciones sobre privacidad de datos**: La gestión de datos fisiológicos sensibles puede generar desconfianza si no se comunica claramente la política de privacidad y seguridad.
|
||||
- **Riesgos de obsolescencia rápida**: Si no se actualiza el producto con nuevas funcionalidades, podría ser superado tecnológicamente en poco tiempo.
|
||||
|
||||
|
||||
|
||||
Datos interesantes sobre el flujo de caja de Erick https://ibb.co/wZv4gBfS
|
||||
@ -1,7 +0,0 @@
|
||||
---
|
||||
tags:
|
||||
- Gestión_de_Proyectos
|
||||
---
|
||||
[[Informe Inicial de Proyecto de gestión de proyectos#Capítulo 1 Introducción al proyecto]]
|
||||
|
||||
Consulta: Como definís la finalización del proyecto. Porque el proyecto puede terminar cuando tengo hecho el prototipo, cuando tengo el producto hecho cuando, etc... Como decido cuando me conviene terminar el proyecto? Porque si fuera el caso de que me contratan para hacer un producto, el proyecto termina cuando se entrega este. Pero si yo estoy haciendo algo con inversión propia como decido cuando terminar? Esto tiene que ver con la investigación previa del mercado? Porque yo me imagino que tengo un par de opciones para los objetivos del proyecto. Puede ser de comercializar yo el producto o puede ser de tratar de conseguir a alguien a quien venderle el proyecto una vez finalizado para comercializarlo. Una idea más es de hacer un proyecto que termina cuando se finaliza el prototipo y en ese momento realizar un segundo proyecto para llevarlo al mercado. Esta ultima forma me parece que no es consistente con l definición o el espíritu de lo que es un proyecto porque uno de los objetivos del proyecto es reponer las inversiones de los que aportaron.
|
||||
@ -1 +0,0 @@
|
||||
- En los objetivos como introduzco la parte de hacer que el MVP cumpla con las normas de productos medicos o "semimedicos".
|
||||
@ -1,348 +0,0 @@
|
||||
---
|
||||
tags:
|
||||
- Gestión_de_Proyectos
|
||||
---
|
||||
El ejemplo en el que se basa este informe se puede ver en el siguiente PDF: [[Template_Gestion_Proyectos_TC024_v2_2.pdf]]
|
||||
|
||||
## 1. Introducción
|
||||
|
||||
El monitoreo del sueño en bebés suele realizarse con tecnologías que requieren contacto físico directo, como sensores adheridos a la piel o bandas ajustadas al cuerpo. Este tipo de soluciones, si bien útiles en ciertos contextos clínicos, resultan invasivas y poco adecuadas para un monitoreo continuo en el tiempo. Su aplicación puede generar molestias, interferir con el descanso natural del bebé e incluso alterar las condiciones que se desean observar.
|
||||
|
||||
Este proyecto busca desarrollar una alternativa no invasiva basada en tecnología de radar UWB (Ultra Wideband), capaz de captar señales relacionadas con la respiración y la actividad cardíaca del bebé sin necesidad de contacto físico. El sistema está diseñado para recopilar datos de forma continua mientras el bebé duerme, con el objetivo de generar reportes periódicos sobre su estado fisiológico, sin interrumpir el descanso.
|
||||
|
||||
El producto está orientado al uso doméstico por familias que deseen contar con una herramienta accesible para observar cómo evoluciona la actividad fisiológica del bebé en su día a día, sin depender exclusivamente de intervenciones médicas. No se trata de un sistema de monitoreo en tiempo real ni de control activo, sino de una solución pensada para el análisis y la observación periódica, desde una perspectiva preventiva.
|
||||
|
||||
El objetivo de este proyecto es construir un **mínimo producto viable (MVP)** que integre el radar UWB, el hardware de procesamiento, los algoritmos de análisis de señal, y una interfaz de consulta digital. Este MVP permitirá validar el funcionamiento del sistema en condiciones reales y sentar las bases para futuras iteraciones del producto.
|
||||
## 2. Definición del proyecto
|
||||
|
||||
El proyecto consiste en el desarrollo de un sistema electrónico no invasivo destinado al monitoreo de funciones vitales —frecuencia respiratoria y cardíaca— en bebés durante el sueño, utilizando tecnología de radar UWB. El producto está concebido como una solución integrada, pensada para funcionar en el hogar, de manera continua y con una experiencia de usuario simple y segura.
|
||||
|
||||
Este artefacto está diseñado para ser utilizado de forma cotidiana durante el sueño del bebé, recolectando datos de manera pasiva, sin contacto físico, y generando reportes periódicos que permitan observar su evolución fisiológica a lo largo del tiempo.
|
||||
|
||||
El sistema se compone de los siguientes bloques principales:
|
||||
|
||||
- **Hardware integrado:** constituye el cuerpo principal del dispositivo y está compuesto por un módulo de radar UWB encargado de adquirir las señales fisiológicas, junto con una unidad de control capaz de mostrar opciones al usuario mediante una interfaz local. Este bloque también permite transmitir los datos recolectados hacia un servidor remoto o estructura externa para su posterior análisis.
|
||||
|
||||
- **Procesamiento de señales:** abarca el diseño del método que permite extraer parámetros fisiológicos relevantes a partir de las señales captadas por el radar, así como la implementación del algoritmo correspondiente. Este procesamiento debe ser robusto frente a ruido e interferencias, y capaz de tolerar movimientos involuntarios típicos del sueño.
|
||||
|
||||
- **Servidor remoto e interfaz de usuario:** este bloque comprende tanto la infraestructura en la nube encargada de recibir, almacenar y procesar los datos enviados por el dispositivo, como la plataforma digital —web o móvil— desde la cual los cuidadores pueden acceder a los reportes generados, visualizar historiales y configurar notificaciones. Este componente articula la comunicación entre el sistema y el usuario final, y constituye la vía principal para consultar la información recolectada.
|
||||
|
||||
La integración de estos bloques permitirá construir un sistema funcional, evaluable en condiciones reales de uso, y alineado con las necesidades del entorno familiar.
|
||||
|
||||
### 2.1. Objetivos
|
||||
|
||||
El objetivo principal es construir un mínimo producto viable (MVP) que integre un conjunto de componentes electrónicos y de software capaces de cumplir esa función en condiciones reales de uso. Este MVP deberá permitir validar la viabilidad técnica, operativa y de experiencia de usuario del sistema, sentando las bases para futuras iteraciones del producto.
|
||||
|
||||
El sistema estará compuesto por los siguientes módulos funcionales:
|
||||
|
||||
- **Un módulo de captura con radar UWB:** encargado de adquirir una señal única relacionada con las microvariaciones del cuerpo del bebé provocadas por la respiración y la actividad cardíaca, utilizando tecnología de radar UWB. Esta señal será utilizada como base para el análisis posterior.
|
||||
|
||||
- **Un método de procesamiento de señales:** estudio y desarrollo de un método que permita extraer parámetros fisiológicos relevantes a partir de la señal adquirida, junto con la implementación de un algoritmo capaz de manejar ruido, interferencias y movimientos involuntarios leves o moderados del bebé.
|
||||
|
||||
- **Una unidad de control del sistema:** componente central que coordina el funcionamiento general del dispositivo, administra el flujo de datos entre módulos y garantiza la operación conjunta del sistema.
|
||||
|
||||
- **Una interfaz embebida de usuario:** compuesta por una pantalla y botones físicos que permitan la configuración del sistema, el inicio o detención del monitoreo y la visualización básica del estado del dispositivo.
|
||||
|
||||
- **Un módulo de conectividad Wi-Fi:** encargado de la transmisión automática y segura de los datos procesados hacia un servidor remoto, incluyendo el manejo de interrupciones de red.
|
||||
|
||||
- **Un servidor en la nube:** infraestructura encargada de recibir, almacenar y procesar los datos enviados desde los dispositivos, con el objetivo de generar reportes e historiales fisiológicos.
|
||||
|
||||
- **Una plataforma web o móvil :** interfaz desde la cual los cuidadores pueden consultar los reportes generados, acceder al historial de mediciones y recibir alertas configurables.
|
||||
|
||||
- **Un gabinete del dispositivo:** estructura externa del sistema que protege los componentes electrónicos, permite una manipulación segura y está adaptada a su uso en un entorno doméstico.
|
||||
|
||||
Además de estos componentes, el proyecto requiere completar los siguientes procesos de desarrollo clave:
|
||||
|
||||
- **Estudio para la generación de mediciones reales:** incluye la recolección de señales reales de sujetos de prueba usando el módulo de medición desarrollado, así como la adquisición de datos complementarios mediante métodos tradicionales u otros medios disponibles. Este proceso tendrá como resultado el banco de mediciones reales y la generación de un patrón de referencia que será utilizado para la validación del método de procesamiento.
|
||||
|
||||
- **Estudio de condiciones de uso y despliegue:** análisis de las situaciones en las que el dispositivo será utilizado, con el objetivo de diseñar un gabinete adecuado y definir las formas de instalación, soporte o integración del producto en su entorno final.
|
||||
|
||||
El alcance del proyecto incluye el diseño, implementación e integración de todos estos módulos, así como su validación en condiciones representativas de uso. El objetivo es lograr un sistema mínimamente viable (MVP), funcional de extremo a extremo, que permita comprobar la viabilidad técnica y de experiencia de usuario del monitoreo remoto no invasivo en el hogar.
|
||||
|
||||
|
||||
### 2.2. Misión y Visión
|
||||
|
||||
**Misión**
|
||||
Desarrollar un sistema tecnológico confiable, no invasivo y accesible para el entorno doméstico, que permita a las familias recopilar datos fisiológicos relevantes —como la frecuencia respiratoria y cardíaca— de sus bebés mientras duermen. El sistema procesará esa información para ofrecer reportes claros y útiles, orientados al seguimiento de la salud del bebé, sin interferir con su descanso ni requerir intervención médica directa.
|
||||
|
||||
**Visión**
|
||||
Contribuir a resolver la falta de soluciones accesibles y no invasivas para el monitoreo de funciones vitales en bebés, brindando una herramienta que permita detectar de forma temprana posibles alteraciones durante el sueño. El proyecto busca facilitar un seguimiento cotidiano que complemente el control pediátrico tradicional, ayudando a reducir riesgos y mejorar el cuidado infantil desde el hogar o en contextos clínicos.
|
||||
|
||||
### 2.3. Entregables mensurables
|
||||
|
||||
El avance del proyecto se medirá a través de tres entregables principales, que representan hitos clave dentro del desarrollo:
|
||||
|
||||
- **Entregable 1: Módulo de medición construido y evaluación de costos**
|
||||
Este entregable corresponde a la finalización del módulo de medición, lo que permite iniciar la generación de mediciones reales.
|
||||
Además, debe realizarse una comparación entre el costo real de construcción del módulo y la estimación original.
|
||||
- Si se detecta una desviación significativa en el presupuesto, deberá actualizarse el análisis de factibilidad económica del proyecto en función de los nuevos costos.
|
||||
|
||||
- **Entregable 2: Prototipo funcional de factibilidad técnica**
|
||||
Este entregable implica la construcción de un prototipo que permita validar la viabilidad técnica del sistema. El prototipo debe:
|
||||
- Adquirir señales fisiológicas reales de una persona.
|
||||
- Transmitir los datos a una computadora mediante conexión Wi-Fi, sin necesidad de un servidor.
|
||||
- Incluir una interfaz embebida básica para interactuar con el sistema.
|
||||
|
||||
- **Entregable 3: Mínimo producto viable (MVP) finalizado**
|
||||
Este entregable representa la integración completa de todos los componentes del sistema, en una versión funcional y coherente. El MVP debe incluir:
|
||||
- Hardware completo y ensamblado, con el radar integrado.
|
||||
- Método de procesamiento de señales operativo.
|
||||
- Interfaz de usuario embebida.
|
||||
- Servidor remoto configurado y funcional.
|
||||
- Aplicación web o móvil accesible para los usuarios.
|
||||
- Estructura física (gabinete) lista para uso final.
|
||||
|
||||
Este entregable representa una versión lista para validación final o para un posible despliegue inicial en contexto real.
|
||||
## 3. Evaluación del proyecto
|
||||
|
||||
### 3.1. Tipo de proyecto
|
||||
|
||||
### 3.2. Evaluación de factibilidad técnica
|
||||
#### 3.2.1. Requerimientos técnicos
|
||||
|
||||
Los requerimientos técnicos abarcan tanto el hardware como el software necesario para el correcto funcionamiento del sistema. A continuación, se detallan los requisitos para cada uno de los componentes clave.
|
||||
|
||||
1. **Requerimientos del Hardware:**
|
||||
- **Módulo de medición (Radar UWB)**:
|
||||
El módulo de medición debe ser capaz de utilizar señales de radar UWB para medir las variables deseadas. Debe tener la capacidad de modular y demodular estas señales, así como muestrear la señal con precisión. Además, debe poder comunicarse con el centro de control para transmitir los datos obtenidos.
|
||||
|
||||
- **Módulo central de control**:
|
||||
El módulo central debe ser capaz de manejar los periféricos conectados, tales como el display, el periférico de comunicación Wi-Fi y el periférico de medición. Este módulo debe garantizar la recuperación de todos los datos generados por el módulo de medición sin pérdida de información, volcando estos datos al módulo Wi-Fi para su transmisión al servidor a través de la red Wi-Fi sin pérdida de datos. La tasa de datos del radar es de aproximadamente **1 megabyte por segundo**, por lo que el módulo de control debe ser capaz de manejar esta cantidad de datos sin comprometer la integridad de la transmisión.
|
||||
|
||||
- **Requisitos de conectividad Wi-Fi**:
|
||||
El módulo Wi-Fi debe ser capaz de conectarse a Internet y manejar un tránsito de datos de aproximadamente 1 megabyte por segundo sin pérdidas. También debe ser capaz de reconectarse automáticamente en caso de fluctuaciones o pérdida de conexión de la señal Wi-Fi.
|
||||
|
||||
2. **Requerimientos del Software:**
|
||||
- El software debe ser capaz de procesar la señal cruda obtenida por el radar, realizar un análisis adecuado y extraer la **frecuencia cardíaca** y la **frecuencia respiratoria** del bebé, lidiando con el ruido presente en la señal.
|
||||
|
||||
- **Mitigación de movimientos**:
|
||||
El software debe ser capaz de identificar y manejar los movimientos del bebé durante la medición. Debe poder filtrar los espasmos y movimientos más pequeños, descartando segmentos de datos no tan significativos sin perder precisión en las estimaciones. Para movimientos más grandes, como cambios de posición, el software debe continuar con la medición y registrar cualquier evento relevante que haya ocurrido.
|
||||
|
||||
3. **Requerimientos del Servidor:**
|
||||
- El servidor debe ser capaz de recibir datos de múltiples usuarios simultáneamente. Debe ser diseñado de manera escalable para manejar el aumento en la cantidad de usuarios y datos sin afectar el rendimiento.
|
||||
|
||||
- El servidor debe procesar los datos obtenidos y generar un informe de los resultados, proporcionando un **pseudo diagnóstico** que brinde información básica sobre el comportamiento del bebé durante la noche.
|
||||
|
||||
4. **Requerimientos de la Aplicación de Usuario:**
|
||||
- La aplicación debe ofrecer varias formas de contacto con la empresa proveedora del servicio para recibir soporte técnico.
|
||||
|
||||
- Debe tener un **historial** de las mediciones realizadas en diferentes días, permitiendo al usuario consultar resultados previos.
|
||||
|
||||
- La aplicación debe contar con un sistema de **notificación** que informe al usuario sobre el diagnóstico generado después de cada medición nocturna.
|
||||
|
||||
#### 3.2.2. Diseño preliminar
|
||||
|
||||
El diseño preliminar del producto abarca tres áreas fundamentales que aseguran su correcto funcionamiento: el hardware, el algoritmo de procesamiento de datos y la interacción del usuario a través del servidor y la aplicación. A continuación, se detallan los componentes y el flujo de trabajo propuestos para cada una de estas áreas.
|
||||
|
||||
1. **Diseño del Hardware:**
|
||||
- **Módulo de radar DWM1000**: Emite y recibe ondas electromagnéticas para medir variaciones y extraer los datos necesarios.
|
||||
- **Raspberry Pi Pico**: Controla los periféricos y gestiona la conectividad Wi-Fi, además de procesar los datos y asegurar la comunicación.
|
||||
- **Display con cuatro botones**: Permite la interacción local con el sistema, visualizando los datos y realizando ajustes básicos.
|
||||
- **Fuente de alimentación**: Suministra energía a los componentes, principalmente al Raspberry Pi Pico y otros módulos conectados.
|
||||
|
||||
2. **Diseño del Software (Algoritmo de Procesamiento de Datos):**
|
||||
- **Análisis espectral**: Utilizado para estimar la **frecuencia respiratoria** a partir de los datos obtenidos por el radar.
|
||||
- **Análisis de formas de onda**: Permite identificar los patrones del ritmo cardíaco, detectando los cuatro ciclos principales presentes en la señal.
|
||||
|
||||
3. **Diseño del Servidor y la Aplicación de Usuario:**
|
||||
- **Servidor**: Se encarga de recibir los datos del dispositivo, procesar las señales y generar alertas automáticas para los usuarios si los parámetros monitoreados exceden los límites establecidos.
|
||||
- **Aplicación de usuario**: Permite la interacción con el sistema, ofreciendo una interfaz para consultar los datos, recibir notificaciones y revisar el historial de mediciones.
|
||||
#### 3.2.3. Inventario de los diferentes aspectos a cubrir
|
||||
|
||||
Para evaluar la factibilidad técnica del proyecto, se identifican los principales componentes y áreas de desarrollo que deben ser abordadas. Estos se agrupan en los siguientes bloques:
|
||||
|
||||
**Hardware del dispositivo**
|
||||
|
||||
- Radar UWB para medición: selección y configuración de un sensor capaz de registrar señales respiratorias y cardíacas de forma no invasiva, con robustez ante ruido y variabilidad del entorno.
|
||||
- Unidad de procesamiento (Raspberry Pi): integración de una unidad capaz de coordinar la adquisición de datos, controlar periféricos y gestionar la operación del sistema.
|
||||
- Pantalla y botones: incorporación de una interfaz embebida que permita navegación simple por menús y visualización de estados del dispositivo.
|
||||
- Sistema de alimentación: diseño de una solución estable, segura y adecuada para uso continuo en un entorno doméstico.
|
||||
|
||||
**Software embebido**
|
||||
|
||||
- Control de periféricos: rutinas de bajo nivel para gestionar sensores, pantalla, botones y comunicación.
|
||||
- Envío de datos al servidor: implementación de un sistema confiable para transferencia de información hacia la nube.
|
||||
- Configuración de red Wi-Fi del usuario: desarrollo de un mecanismo simple y seguro para vincular el dispositivo con la red doméstica.
|
||||
- Gestión del sistema (máquina de estados): estructura lógica que permita escalar el software, navegar entre modos de operación y mantener estabilidad del sistema.
|
||||
|
||||
**Diseño físico del gabinete**
|
||||
|
||||
- Estudio de estabilidad y colocación: análisis del comportamiento del producto en diferentes ubicaciones dentro del hogar, para asegurar un funcionamiento correcto.
|
||||
- Desarrollo del gabinete físico: diseño de una carcasa resistente a condiciones comunes (polvo, humedad), fácil de ensamblar, reparar y mantener en el tiempo.
|
||||
|
||||
**Infraestructura del servidor**
|
||||
|
||||
- Comunicación con los dispositivos cliente: desarrollo de canales estables, seguros y escalables para recibir datos desde los dispositivos instalados.
|
||||
- Procesamiento de señales remoto: implementación del algoritmo de análisis sobre los datos enviados desde el hardware.
|
||||
- Generación de alertas y notificaciones: sistema que permita informar a los usuarios ante eventos o situaciones relevantes.
|
||||
- Diseño escalable: arquitectura orientada a permitir el crecimiento progresivo del sistema sin comprometer su estabilidad.
|
||||
|
||||
**Aplicación para el usuario**
|
||||
|
||||
- Canal de comunicación con el proveedor: espacio dentro de la app donde el usuario pueda contactarse directamente para soporte o consultas.
|
||||
- Seguridad de la aplicación: autenticación de usuarios, manejo de datos sensibles y protección frente a accesos no autorizados.
|
||||
- Sincronización con el servidor: integración fluida entre la app y el backend para consultar información en tiempo real o diferido.
|
||||
|
||||
**Organización interna para operación continua**
|
||||
|
||||
- Área de producción: fabricación, ensamblaje y control de calidad de unidades nuevas.
|
||||
- Área de ventas: promoción, comercialización y atención pre-venta.
|
||||
- Área de atención y soporte técnico al cliente: resolución de consultas, problemas o incidencias durante el uso del producto.
|
||||
- Área de mantenimiento y reacondicionamiento: gestión de stock, reparación de equipos devueltos y control logístico de componentes.
|
||||
- Área de operación del servidor y la app: monitoreo, mantenimiento y actualización continua de las plataformas digitales.
|
||||
- Área de desarrollo técnico: evolución del hardware y software del sistema, investigación de nuevas funcionalidades y mejoras.
|
||||
### 3.3. Evaluación de factibilidad de negocios
|
||||
|
||||
A continuación se desarrolla un análisis de fortalezas, oportunidades, debilidades y amenazas vinculadas al desarrollo y despliegue del proyecto.
|
||||
#### 3.3.1. Análisis FODA
|
||||
##### 3.3.1.1. Fortalezas
|
||||
|
||||
- **Vínculo con un instituto de investigación especializado**: Existe un contacto activo con una institución que investiga las tecnologías involucradas, lo que aporta respaldo técnico y acceso a conocimiento actualizado.
|
||||
- **Base técnica sólida del equipo**: El equipo cuenta con formación en electrónica, software y procesamiento de señales, lo que permite abordar internamente los principales desafíos tecnológicos.
|
||||
- **Bajo costo del diseño de hardware**: El diseño inicial proyecta un costo reducido para los componentes, permitiendo desarrollar el MVP con recursos moderados.
|
||||
- **Escalabilidad del producto**: La solución es adaptable para nuevas funcionalidades, como la detección de distintas patologías, lo que habilita la expansión a otros nichos de mercado en el futuro.
|
||||
- **Control de desarrollo in-house**: Al ser un desarrollo propio, se puede iterar rápidamente sin depender de terceros o licencias de software/hardware externas.
|
||||
- **Alta diferenciación funcional**: El enfoque no invasivo para monitoreo vital en bebés es único dentro del segmento doméstico, lo que otorga una ventaja clara frente a otros productos.
|
||||
|
||||
##### 3.3.1.2. Oportunidades
|
||||
|
||||
- **Tecnología UWB segura y aprobada**: El uso de radar UWB ya está regulado y validado para entornos humanos, facilitando su homologación médica.
|
||||
- **Falta de dispositivos similares en el mercado**: Actualmente no existen productos que monitoreen ritmo respiratorio y cardíaco en bebés de forma no invasiva, lo que representa una oportunidad de innovación.
|
||||
- **Tendencia en crecimiento del interés por UWB**: La tecnología está en expansión en distintas aplicaciones, y su adopción genera un entorno favorable para el desarrollo de productos basados en ella.
|
||||
- **Envejecimiento de otras tecnologías en uso**: Muchos monitores actuales se basan en sensores de contacto o bandas físicas, tecnologías que presentan limitaciones frente a la propuesta UWB.
|
||||
- **Potencial interés de organismos de salud**: Si se demuestra precisión y utilidad clínica, el producto podría interesar a hospitales, neonatologías y programas de salud pública.
|
||||
- **Acceso a subsidios y programas de innovación**: El carácter tecnológico y biomédico del proyecto podría hacerlo elegible para fondos públicos o privados de I+D.
|
||||
|
||||
##### 3.3.1.3. Debilidades
|
||||
|
||||
- **Falta de perfiles técnicos clave**: El equipo actual no cuenta con especialistas en desarrollo de servidores, aplicaciones móviles ni asesoramiento médico.
|
||||
- **Ausencia de colaboración con equipos médicos**: No existen vínculos establecidos con instituciones o profesionales médicos que puedan validar o mejorar el enfoque clínico del producto.
|
||||
- **Poca experiencia en desarrollo de productos**: El equipo no cuenta con antecedentes en el diseño, testeo y despliegue de prototipos o MVPs para el mercado.
|
||||
- **Falta de financiación asegurada**: Actualmente no se dispone de los fondos necesarios para llevar a cabo el desarrollo completo del sistema.
|
||||
- **Proceso regulatorio incierto**: Aunque la tecnología UWB esté aprobada, la certificación del dispositivo completo puede requerir conocimientos y procesos complejos.
|
||||
- **Limitada experiencia en diseño industrial**: El diseño físico del gabinete puede presentar dificultades si no se cuenta con especialistas en producto o ergonomía.
|
||||
|
||||
##### 3.3.1.4. Amenazas
|
||||
|
||||
- **Competencia indirecta en el mercado de monitoreo infantil**: Existen múltiples productos que, aunque no miden los mismos parámetros, podrían ser percibidos como soluciones alternativas.
|
||||
- **Condiciones económicas desfavorables**: El producto podría ser considerado de nicho o de lujo, lo que limitaría su adopción en contextos de baja capacidad adquisitiva o crisis económica.
|
||||
- **Barrera regulatoria y legal**: El proceso de homologación para uso médico puede extenderse, complejizarse o implicar altos costos.
|
||||
- **Aceleración de competidores tecnológicos**: Empresas con mayor capital podrían lanzar productos similares más rápido, con más marketing o distribución.
|
||||
- **Preocupaciones sobre privacidad de datos**: La gestión de datos fisiológicos sensibles puede generar desconfianza si no se comunica claramente la política de privacidad y seguridad.
|
||||
- **Riesgos de obsolescencia rápida**: Si no se actualiza el producto con nuevas funcionalidades, podría ser superado tecnológicamente en poco tiempo.
|
||||
### 3.4. Análisis de mercado y financiero
|
||||
|
||||
#### 3.4.1. Análisis de mercado y publico objetivo
|
||||
|
||||
El público objetivo de este producto son padres de bebés recién nacidos que desean contar con una herramienta tecnológica para el monitoreo del estado de salud de sus hijos mientras duermen. A diferencia de otros sistemas que requieren atención constante por parte de los cuidadores, este dispositivo está pensado para funcionar de manera autónoma, permitiendo que los padres reciban información relevante, sin la necesidad de estar monitoreando activamente al bebé en todo momento. Esto lo convierte en una solución ideal para familias que buscan tranquilidad y seguridad durante el sueño del bebé, sin sobrecargar su rutina con vigilancia permanente.
|
||||
|
||||
Se realizó un análisis de mercado para identificar el público potencial del producto, evaluando la demanda estimada y los factores que pueden influir en su adopción. Inicialmente, se analizó la competencia existente en el mercado, considerando productos con funciones relacionadas al monitoreo infantil como los baby calls (intercomunicadores de bebés) y las cámaras de monitoreo. Aunque estos dispositivos no cumplen exactamente las mismas funciones que el producto propuesto, podrían ser percibidos por los usuarios como soluciones alternativas. El objetivo de este análisis fue estimar la cantidad de ventas mensuales de estos productos para tener una referencia sobre el tamaño del mercado activo. Sin embargo, no fue posible obtener cifras públicas de ventas debido a la falta de datos oficiales disponibles, lo que limitó esta vía de análisis.
|
||||
|
||||
Frente a esta limitación, se optó por realizar un análisis demográfico basado en la cantidad de nacimientos mensuales en la región del AMBA (Área Metropolitana de Buenos Aires), como una forma de estimar el mercado potencial de familias que podrían estar interesadas en adquirir el producto. Para obtener una visión más ajustada a la realidad socioeconómica del público objetivo, se filtraron los datos considerando únicamente los nacimientos en hospitales privados y aquellos cubiertos por obras sociales, dado que este grupo representa a las familias con mayor capacidad adquisitiva y mayor probabilidad de invertir en un sistema de monitoreo infantil avanzado.
|
||||
|
||||
De los datos recopilados, se obtuvo que en el AMBA nacen aproximadamente 22.000 bebés mensualmente. Cuando se limita el análisis a los nacimientos en hospitales privados y con cobertura de obra social, el número se reduce a alrededor de 9.500 nacimientos mensuales. Considerando estos datos, se puede estimar de forma conservadora que al menos la mitad de estas familias podría formar parte del mercado potencial de compradores del producto, lo que representa un universo significativo de usuarios posibles.
|
||||
|
||||
Este análisis permite concluir que la principal limitación del proyecto no radica en la cantidad de personas que podrían comprar el producto, sino en la capacidad de la organización para captar a esos clientes y, fundamentalmente, en la infraestructura técnica necesaria para brindar el servicio de forma continua y confiable. El reto principal será desarrollar una estrategia efectiva de llegada al cliente, así como tener la capacidad operativa de producción, despliegue y soporte técnico de la solución.
|
||||
|
||||
#### 3.4.2. Análisis de competidores y sustitutos
|
||||
|
||||
Las alternativas actuales disponibles en el mercado para el monitoreo domiciliario de bebés son las siguientes:
|
||||
|
||||
- Owlet Dream Sock: Es un dispositivo diseñado para monitorear de manera domiciliaria la frecuencia cardíaca y la oxigenación del bebé durante el sueño. Funciona a través de un sensor que se coloca en el pie y envía los datos a una aplicación móvil, donde los padres pueden visualizar el estado del bebé y recibir alertas ante posibles eventos anómalos. El costo es de entre 299 y 399 dólares.
|
||||
- Cámaras de monitoreo para bebés (como Nanit Pro, Lollipop Cam, CuboAi): Son cámaras inteligentes que permiten ver y escuchar al bebé en tiempo real desde un teléfono móvil. Algunos modelos avanzados incorporan alertas de movimiento o patrones de respiración mediante análisis de imagen, pero no miden signos vitales reales. El costo de estos dispositivos va de 150 a 300 dólares.
|
||||
- Baby Call (monitor de audio tradicional): Son dispositivos simples que transmiten audio desde la habitación del bebé. Algunos modelos también incluyen video, pero en general su función es escuchar al bebé mientras duerme. No brindan información sobre parámetros fisiológicos. El costo se encuentra entre 30 y 80 dólares.
|
||||
- No hacer nada: Consiste en la supervisión tradicional de los padres sin utilizar tecnología adicional. No genera costos económicos, pero implica un mayor nivel de atención directa y no ofrece mecanismos de alerta automática ante eventos críticos.
|
||||
|
||||
#### 3.4.3. Análisis de proyecto similar
|
||||
|
||||
En esta sección se analiza un producto similar al desarrollado en este proyecto con el fin de identificar antecedentes relevantes, aprender de experiencias previas y entender posibles riesgos asociados a productos de características comparables. Este ejercicio permite obtener información sobre el mercado, las dificultades técnicas y los desafíos comerciales que pueden surgir en la implementación de soluciones similares.
|
||||
|
||||
Durante el análisis de competencia se identificó un producto comparable en concepto: el **Miku Pro Smart Baby Monitor**. Este dispositivo combinaba una cámara con un sistema de monitoreo no invasivo capaz de medir tanto la frecuencia cardíaca como la frecuencia respiratoria de los bebés mientras dormían. El monitoreo se realizaba en tiempo real y sin contacto físico con el niño, lo cual lo posicionaba como una tecnología avanzada dentro de su segmento.
|
||||
|
||||
Sin embargo, este producto fue retirado del mercado en 2023 tras la bancarrota de la empresa desarrolladora. Uno de los aspectos distintivos del Miku Pro era el uso de componentes de precisión militar para realizar el análisis de señales, lo cual si bien aportaba un alto nivel tecnológico, probablemente contribuyó a un costo excesivamente alto que pudo haber dificultado su comercialización masiva y sostenibilidad en el tiempo.
|
||||
|
||||
Este caso representa un ejemplo valioso de un producto similar al propuesto que no logró consolidarse en el mercado. Aunque el hecho de que un proyecto comparable haya fallado no es necesariamente una buena noticia, permite extraer aprendizajes sobre los riesgos de sobredimensionar el producto en términos de tecnología o costos, y pone en evidencia la importancia de lograr un equilibrio adecuado entre funcionalidad, precio y viabilidad comercial.
|
||||
|
||||
|
||||
## 4. Planificación del proyecto
|
||||
### 4.1. Plan de producto
|
||||
|
||||
El desarrollo del producto contempla distintas versiones evolutivas que permiten mejorar la propuesta de valor y aumentar la utilidad para los usuarios. Estas iteraciones permiten ampliar las funcionalidades del sistema, adaptarse a nuevas necesidades y ofrecer un producto competitivo frente a otras soluciones del mercado.
|
||||
|
||||
A continuación se detallan posibles caminos de evolución del producto.
|
||||
|
||||
#### 4.1.1. Integración de función de Baby Calling
|
||||
|
||||
Uno de los productos con los que compite indirectamente esta solución es el baby call o intercomunicador de bebés, un dispositivo cuya función principal es transmitir audio desde la habitación del bebé hacia los padres o cuidadores.
|
||||
|
||||
Una posible evolución del sistema actual es incorporar esta funcionalidad, añadiendo un **micrófono al dispositivo y permitiendo la transmisión de audio en tiempo real a través de la aplicación del usuario**.
|
||||
|
||||
Esta mejora implicaría:
|
||||
|
||||
- Una actualización del hardware con la incorporación de un módulo de captura de audio.
|
||||
- Una actualización de la aplicación para integrar la función de escucha remota.
|
||||
- Un agregado de valor importante, ya que el usuario podría tener en un solo dispositivo tanto el monitoreo vital como el monitoreo sonoro.
|
||||
|
||||
#### 4.1.2. Detección de problemas en tiempo real
|
||||
|
||||
Una segunda evolución significativa consiste en desarrollar la capacidad de **detectar eventos críticos de salud en tiempo real**. Actualmente, el sistema está pensado para procesar datos y reportar información acumulada; sin embargo, podría evolucionar hacia un sistema de alerta inmediata.
|
||||
|
||||
Esto permitiría identificar eventos como:
|
||||
|
||||
- Apneas
|
||||
- Episodios de asma
|
||||
- Alteraciones en la frecuencia respiratoria o cardíaca durante el sueño
|
||||
|
||||
Esta mejora implicaría:
|
||||
|
||||
- Desarrollar algoritmos más complejos de procesamiento de señales en tiempo real.
|
||||
- Optimizar el flujo de comunicación para generar alertas inmediatas al usuario.
|
||||
- Integrar un sistema de notificaciones críticas a través de la app.
|
||||
|
||||
#### 4.1.3. Incorporación de monitoreo por cámara
|
||||
|
||||
Otra versión evolutiva posible es **la incorporación de un sistema de video**, sumando al hardware una cámara que permita al usuario visualizar al bebé en todo momento.
|
||||
|
||||
Esto permitiría:
|
||||
|
||||
- Monitoreo visual complementario al monitoreo vital.
|
||||
- Integración en la aplicación móvil de una interfaz para transmisión y visualización de video en vivo.
|
||||
|
||||
Esta evolución acercaría al producto a una solución integral de monitoreo, ofreciendo múltiples canales de información para el usuario (vitales + sonido + imagen).
|
||||
### 4.2. Organización del proyecto
|
||||
|
||||
La organización del proyecto se estructura en dos etapas principales, cada una con un equipo de trabajo adaptado a las necesidades y objetivos de esa fase:
|
||||
|
||||
#### 4.2.1. Equipo de trabajo
|
||||
|
||||
##### 4.2.1.1. Equipo de desarrollo (prototipo y MVP)
|
||||
|
||||
Esta etapa corresponde al diseño, construcción y validación del producto, incluyendo tanto el desarrollo del prototipo como la construcción del Mínimo Producto Viable (MVP).
|
||||
|
||||
El equipo está conformado por los siguientes perfiles:
|
||||
|
||||
- **3 ingenieros electrónicos**: responsables del diseño del hardware del producto, el desarrollo del sistema embebido, y además de la investigación y desarrollo del algoritmo de procesamiento de señales. Este equipo será el encargado de definir los métodos de análisis de datos, implementar los algoritmos correspondientes y obtener mediciones reales para la validación del sistema.
|
||||
- **Consultor médico**: un profesional médico que asesora en aspectos clínicos, colabora en el proceso de recolección de mediciones y orienta al equipo en cuestiones relativas a salud y biomedicina.
|
||||
- **2 ingenieros informáticos**: encargados de la programación del servidor, la arquitectura de backend y la implementación de la aplicación que utilizan los usuarios para interactuar con el sistema.
|
||||
|
||||
##### 4.2.1.2. Equipo de operación (post-lanzamiento y ventas)
|
||||
|
||||
Una vez finalizado el desarrollo del MVP y comenzada la etapa comercial, el proyecto requiere un equipo orientado a la producción, comercialización y mantenimiento del producto en el mercado.
|
||||
|
||||
El equipo de operación incluye los siguientes roles:
|
||||
|
||||
- **Ingeniero electrónico de producción y soporte**: encargado de la fabricación en serie, el control de calidad y la reparación de dispositivos en caso de fallas o devoluciones.
|
||||
- **Responsable de ventas y stock**: encargado de la gestión comercial, manejo del inventario de productos y administración del flujo de ventas.
|
||||
- **Encargado de atención al cliente**: responsable de recibir consultas, coordinar reposiciones o reemplazos de equipos, y brindar soporte post-venta a los usuarios. También debe gestionar la logística de stock para garantizar la disponibilidad de equipos de reemplazo.
|
||||
- **Ingeniero informático de mantenimiento**: encargado del mantenimiento y actualización del servidor y de la aplicación utilizada por los clientes, asegurando la operación continua del sistema.
|
||||
#### 4.2.2. Recursos necesarios
|
||||
##### 4.2.2.1. Infraestructura
|
||||
##### 4.2.2.2. Equipamiento
|
||||
|
||||
Para la ejecución del proyecto se requiere un conjunto específico de equipamiento técnico y herramientas. Cada uno de los integrantes del equipo utilizará su computadora personal para el desarrollo de software, procesamiento de datos y tareas de gestión. Aunque estos equipos no pertenecen formalmente a la empresa, forman parte esencial de los recursos de trabajo. Además, se necesita un espacio equipado para el montaje de hardware, incluyendo herramientas de soldadura y una mesa de trabajo dedicada a la fabricación y ensamblado de los módulos electrónicos.
|
||||
|
||||
Para la validación de las mediciones y la obtención de datos de referencia, se utilizarán equipos biomédicos tradicionales como un estetoscopio electrónico, que permitirá registrar la frecuencia respiratoria, y un oxímetro Bluetooth, necesario para medir la frecuencia cardíaca de manera complementaria. Estos dispositivos son fundamentales para generar el banco de datos comparativo que se utilizará en la etapa de prueba y ajuste del algoritmo de procesamiento de señales.
|
||||
##### 4.2.2.3. Insumos
|
||||
|
||||
##### 4.2.2.4. Servicios
|
||||
##### 4.2.2.5. Otros
|
||||
@ -1,86 +0,0 @@
|
||||
---
|
||||
tags:
|
||||
- Gestión_de_Proyectos
|
||||
---
|
||||
# Detección de anomalías cardiorrespiratorias a través de radares UWB
|
||||
## 1. Capítulo 1: Introducción al proyecto
|
||||
|
||||
El proyecto tiene como objetivo la generación de un producto que mediante el uso de la tecnología de radares UWB (Ultra Wide Band) detectar y leer las señales respiratorias y cardíacas de una persona. Una vez obtenida esta información en tiendo real, realizar una detección de forma continua de anomalías utilizando la señal respiratoria, como por ejemplo: prevención de ataques de asma o apnea del sueño.
|
||||
|
||||
Para explicar este proyecto, vamos a seccionar la explicación de este en tres partes: el radar, el
|
||||
procesamiento de los datos y el algoritmo de detección/clasificación de anomalías.
|
||||
|
||||
==El proyecto consiste en la generación de una antena que pueda emitir ondas electromagnéticas para detectar la respiración de una persona y del ritmo cardiaco. Una vez obtenida la señal electromagnética de la antena hay que procesar la señal para obtener los datos de ritmo cardiaco y ritmo respiratorio. Finalmente hay que hacer una clasificación de las señales para identificar anomalías en el paciente.== (Esta sección resaltada elijo dejarla como parte anecdótica y no perder la fuente del desarrollo actual)
|
||||
|
||||
### 1.1. El radar
|
||||
|
||||
Para llevar a cabo este proyecto, una de las tecnologías que se elige usar es la tecnología de radar UWB. Básicamente el proyecto esta formado al rededor de la esta tecnología ya que existen ejemplos trabajos específicos que lograron objetivos similares. Además la tecnología esta bastante desarrollada y ya existen antenas comerciales que permiten utilizar un radar UWB.
|
||||
|
||||
Que es un radar UWB? Los radares UWB (Ultra Wide Band) son radares que se caracterizan por tener anchos de banda muy grandes (por eso Ultra Wide Band) para la frecuencia central que utilizan. En general, estos radares trabajan con anchos de banda mayores que los 500 MHz o ancho de banda fraccional mayor a $0.2$ . El ancho de banda fraccional se define como:
|
||||
$$
|
||||
B_{frac} = \frac{2(f_H - f_L)}{f_H + f_L}
|
||||
$$
|
||||
Estos radares nos permiten generar impulsos con mucha definición, que es una gran ventaja en varios aspectos. Por ejemplo, estos impulsos tienen un gran poder de penetración de objetos.
|
||||
|
||||
### 1.2. El procesamiento de la señal
|
||||
|
||||
Nosotros buscamos extraer información de los datos "crudos" que nos proporciona el radar. Lo que queremos extraer es el ritmo cardiaco y el ritmo respiratorio de la persona, u señales similares que nos den la información necesaria para poder buscar anomalías. Para poder obtener esta información tenemos que hacer un procesamiento de la señal que sale del radar. Cuales son los desafíos o complicaciones que vamos a tener en esta sección? Yo pude identificar 4 problemas principales que hay sobre los cuales hay que tomar decisiones de alcance para poder definir bien el proyecto. Estos problemas son:
|
||||
- Lidiar con el ruido que tiene la señal
|
||||
- Lidiar con el clutter que recibe el radar
|
||||
- Lidiar con los movimientos molestos o involuntarios que tiene la persona y molestan nuestro análisis
|
||||
- Definir el método de análisis de señal para obtener nuestras señales biológicas.
|
||||
|
||||
#### 1.2.1. El Clutter de la señal
|
||||
|
||||
Que es el clutter de la señal? El clutter es un fenómeno que se produce en las señales de radar. El clutter es el revote de la señal electromagnética enviada por el radar en los alrededores que no son nuestro blanco. Como nuestra identificación de elementos se basa en el rebote de la señal electromagnética, si hay elementos al rededor de nuestro blanco, estos van a generar señales de rebote que van a ensuciar nuestra señal. Es por esto que hay que poder lidiar con el clutter de la señal de entrada a la antena.
|
||||
|
||||
#### 1.2.2. Movimientos de la persona
|
||||
|
||||
Para entender porque los movimientos involuntarios o molestos de la persona objetivo nos dificultan el análisis y hay que lidiar con ellos, hay que entender que lo que se esta midiendo con la señal de radar es la distancia entre el radar y la persona objetivo. Como se utiliza esta variación de distancia para determinar la frecuencia cardiaca y la respiratoria, cualquier variación de distancia que no pertenezca a estas dos fuentes nos va a dificultar y estorbar la estimación.
|
||||
Entendiendo esto, podemos pensar en tres clases de movimientos diferentes que puede hacer una persona (tener en cuenta que esta es una clasificación personal no extraída de la bibliografía):
|
||||
- **Espasmos**: Movimientos muy pequeños de la persona que afectan una pequeña cantidad de muestras. Estos movimientos pueden ser causados por espasmos musculares o algún otro tipo de movimiento muy pequeño.
|
||||
- **Movimientos corporales**: estos movimientos son movimientos mucho mas grandes que invalidan grandes secciones de datos. Estos movimientos pueden ser: movimientos de las extremidades que mantienen el torso quieto, variaciones de distancia entre la persona y el radar o pequeñas rotaciones del torso que vuelve a su estado inicial.
|
||||
- **Rotaciones (dramáticas) del torso**: Este es un movimiento radical que modifica la modelación que se tenia hecha hasta el momento del movimiento, lo que lleva a un problema de discontinuidad de las mediciones y la necesidad de una remodelación. Algo que se tiene que tener en cuenta es que esta re-modelación del problema puede tener que ser tanto dentro del programa como en la estructura física que se estableció para las mediciones.
|
||||
|
||||
#### 1.2.3. Método de procesamiento
|
||||
|
||||
Para poder tanto la frecuencia cardiaca como la respiratoria se va a tener que hacer un análisis espectral de la señal que se recibe. Para poder definir el tipo de análisis que se va a hacer se va a tener que hacer una investigación de los distintos métodos y seleccionar aquel que sea mas oportuno para nuestro caso de aplicación.
|
||||
|
||||
### 1.3. Detección de anomalías
|
||||
|
||||
Esta tercera sección del proyecto tomaría la forma de una algoritmo de clasificación o de detección sobre la señal procesada (Inteligencia artificial aplicado al caso). Esto quiere decir que se tiene que utilizar una base de datos de mediciones realizadas para entrenar un algoritmo y poder realizar la clasificación o detección.
|
||||
Un punto importante de esta sección es la selección del modelo de clasificación/detección que se conviene utilizar.
|
||||
|
||||
|
||||
## 2. Capítulo 2: Clasificación del proyecto
|
||||
|
||||
Cuales son las características del proyecto? Como se quiere generar un producto para que pueda ser utilizado para los padres que tienen chichos con problemas respiratorios como principal consumidor esto nos lleva a pensar que hay dos formas principales para la venta del producto. La primera es generar un producto que sea masivo y que este pensado al rededor de que cada familia sea capaz de utilizarlo independientemente sin la asistencia externa, mientras que la segunda opción es generar un producto que pueda ser fácilmente modificado dependiendo de las necesidades de cada cliente y además ofrecer asistencia para la utilización del producto.
|
||||
|
||||
## 3. Capítulo 3: FODA
|
||||
|
||||
### 3.1. Fortalezas
|
||||
- Ya estoy en contacto con investigadores que trabajaron sobre el tema.
|
||||
- Tengo una buena comprensión de los temas fundamentales para comenzar a hacer la investigación necesaria para el desarrollo.
|
||||
|
||||
### 3.2. Oportunidades
|
||||
- Hay bastante investigación hecha sobre el tema.
|
||||
- Ya hay una compañía que produce de forma comercial la antena que se puede utilizar para el proyecto por lo que el desarrollo e investigación que hay que hacer es son sobre el software y a lo sumo sobre el hardware sobre el que se corre.
|
||||
- Es un proyecto escalable en el sentido de que una vez finalizado el proyecto, este se puede utilizar para formular otros expandiendo el alcance de la utilización de la tecnología
|
||||
- La tecnología de UWB ya esta categorizada como segura por la (Insertar cual organización es) por lo que no habría tantos problemas para el aval del uso de la tecnología.
|
||||
|
||||
### 3.3. Debilidades
|
||||
- Si quiero desarrollar una inteligencia artificial para hacer una detección de anomalías no se si existen bases de datos para entrenarlas y en el caso de que no existan hay que crearlas lo cual trae mucho trabajo.
|
||||
- Al tener que resolver tantas cuestiones dentro del proyecto, este tiene una gran complejidad y quizás es mucho para hacer solo, lo que se va a reflejar en una gran carga de trabajo o en una mayor duración del proyecto.
|
||||
- No conozco el mercado en el cual se adentraría el producto final, lo que dificulta la definición de las especificaciones técnicas del prototipo.
|
||||
|
||||
### 3.4. Amenazas
|
||||
- Hay mucha investigación publica hecha sobre el tema por lo que alguien mas podría estar desarrollando el proyecto.
|
||||
- La compañía que produce las antenas es una empresa extranjera por lo que estaría atado a importar el producto a menos que desarrolle mi propio radar, idea que es poco factible a corto plazo.
|
||||
- Haciendo un análisis de oportunidades en conjunto a la situación económica del país no creo que sea una buena inversión de tiempo y dinero el proyecto del prototipo para después buscar generar una empresa.
|
||||
|
||||
## 4. Capítulo 4: Alcances del proyecto
|
||||
|
||||
Este proyecto se propone como objetivo la creación de un prototipo de una detector de anomalías cardiorrespiratorias utilizando radares UWB. Este prototipo se busca que sea algo similar a una prueba de concepto para lo que puede ser luego un producto comercial, por lo que en el diseño de este prototipo lo que se busca es más de llegar al objetivo de que funcione mas que en los elementos de conveniencia del consumidor. Esto quiere decir que quedan fuera del alcance de este proyecto objetivos que tienen en cuenta la facilidad de uso y posicionamiento del/los radares, planificación de ayuda al consumidor o interacción con los consumidores del producto. Estos temas quedaran para una iteración posterior de este producto.
|
||||
|
||||
|
||||
PMI o PMBOK
|
||||
@ -1,19 +0,0 @@
|
||||
Hablé con Cecilia de mis preocupaciones sobre la materia de Gestión de proyectos electrónicos y planteando le mis preocupaciones sobre una manera de encapsular dentro de un producto/proyecto el tema sobre el que estoy investigando. Ella me hizo una propuesta de un proyecto que cumple con los requisitos de lo que estoy necesitando.
|
||||
|
||||
La propuesta de Cecilia es un producto que sea un medidor de signos vitales, es decir respiración y ritmo cardíaco, para mascotas cuando hay que hacer una cirugía.
|
||||
|
||||
- un elemento que te permita tomar las muestras del animal (el radar y el circuito auxiliar)
|
||||
- el desarrollo del software de procesamiento de la señal
|
||||
- el desarrollo de del hardware donde se van a guardar los datos y se van a procesar esos datos
|
||||
- el desarrollo de la interfaz donde se pueden visualizar los datos de salida para el personal medico.
|
||||
- el desarrollo del gabinete donde se va a albergar todos estos dispositivos
|
||||
- la generación del la base de datos con la que se va a probar el software generado.
|
||||
|
||||
Ahora, una cuestión que hay que recordar es que la proposición de proyecto que estoy haciendo yo es la generación del ==prototipo== y no la del producto final por lo que no es necesario desarrollar todos los puntos. Los puntos que quizás no hay que producir para el prototipo son:
|
||||
- El gabinete, como es una etapa de prototipo con un diseño básico y rustico en software, asumo que es suficiente.
|
||||
- el hardware de visualización es necesario diseñarlo y probar que funciona pero nada mas. Pero se puede hacer la parte mas importante de esto, por ejemplo, me imagino que no es necesario probar de hacer una alimentación integrada con el circuito.
|
||||
- El radar y el circuito auxiliar ya fue inventado por lo que solo es necesario producirlo.
|
||||
|
||||
Cual es el problema que busca solucionar este producto? No hay buenos elementos de medición de signos vitales para animales en situaciones de cirugía. Un ejemplo es un oxímetro para perro. Este producto es una mutación del oxímetro para humanos pero no resuelve bien algunos problemas que no existen al medir humanos pero si existen al medir perros.
|
||||
Entonces, la búsqueda de este proyecto es generar un producto que sea pueda ser utilizado por veterinarios en situaciones de cirugías y que pueda informar el ritmo cardíaco y el ritmo respiratorio del animal.
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 49 KiB |
Binary file not shown.
@ -1,15 +0,0 @@
|
||||
![[Pasted image 20250514132214.png]]
|
||||
|
||||
|
||||
- [Electromagnetics in Magnetic Resonance Imaging](https://iopscience.iop.org/book/mono/978-1-6817-4083-6)
|
||||
Physical Principles, Related Applications, and Ongoing Developments
|
||||
|
||||
- https://www.edn.com/coreless-power-design-for-high-magnetic-field-environments/
|
||||
|
||||
- https://radiopaedia.org/articles/mri-electronics-and-data-processing?lang=us
|
||||
- Magnetic Resonance Technology: Hardware and System Component Design_Check Access_
|
||||
|
||||
- https://radiologykey.com/magnetic-resonance-imaging-hardware/
|
||||
- https://link.springer.com/article/10.1007/s00247-020-04894-9
|
||||
- https://www.ncbi.nlm.nih.gov/books/NBK564320/
|
||||
- https://www.edn.com/coreless-power-design-for-high-magnetic-field-environments/
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 54 KiB |
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
@ -1,15 +0,0 @@
|
||||
![[Pasted image 20250514132214.png]]
|
||||
|
||||
|
||||
- [Electromagnetics in Magnetic Resonance Imaging](https://iopscience.iop.org/book/mono/978-1-6817-4083-6)
|
||||
Physical Principles, Related Applications, and Ongoing Developments
|
||||
|
||||
- https://www.edn.com/coreless-power-design-for-high-magnetic-field-environments/
|
||||
|
||||
- https://radiopaedia.org/articles/mri-electronics-and-data-processing?lang=us
|
||||
- Magnetic Resonance Technology: Hardware and System Component Design_Check Access_
|
||||
|
||||
- https://radiologykey.com/magnetic-resonance-imaging-hardware/
|
||||
- https://link.springer.com/article/10.1007/s00247-020-04894-9
|
||||
- https://www.ncbi.nlm.nih.gov/books/NBK564320/
|
||||
- https://www.edn.com/coreless-power-design-for-high-magnetic-field-environments/
|
||||
@ -1,75 +0,0 @@
|
||||
Los requisitos de compatibilidad electromagnética (CEM) que establece la norma **IEC 60601-2-33** para equipos de resonancia magnética (RM) se basan en los principios generales de la norma IEC 60601-1-2, que es la norma colateral de CEM aplicable a todos los equipos electromédicos, y se complementan con aspectos particulares para RM. En concreto, la IEC 60601-2-33 incorpora:
|
||||
|
||||
- **Inmunidad electromagnética**: El equipo de RM debe ser capaz de funcionar correctamente sin degradación del rendimiento cuando está expuesto a interferencias electromagnéticas típicas en entornos clínicos, como campos de radiofrecuencia, impulsos eléctricos o perturbaciones de baja frecuencia.
|
||||
|
||||
- **Emisiones electromagnéticas**: El equipo debe limitar las emisiones electromagnéticas para no interferir con otros dispositivos médicos o electrónicos cercanos, garantizando que no se produzcan perturbaciones que afecten la seguridad o el funcionamiento de otros equipos.
|
||||
|
||||
- **Pruebas y evaluación**: Se deben realizar pruebas específicas de compatibilidad electromagnética siguiendo los métodos y límites establecidos en IEC 60601-1-2, adaptados a las características particulares de los sistemas de RM.
|
||||
|
||||
- **Diseño y mitigación**: La norma exige que el diseño del equipo incluya medidas para reducir la susceptibilidad y las emisiones electromagnéticas, tales como blindajes, filtros, y diseño de circuitos y cables.
|
||||
|
||||
- **Documentación y marcado**: El fabricante debe proporcionar información clara sobre las condiciones de uso para garantizar la compatibilidad electromagnética, incluyendo advertencias o instrucciones para evitar interferencias.
|
||||
|
||||
- **Referencias normativas**: IEC 60601-2-33 hace referencia explícita a IEC 60601-1-2 para los requisitos generales de CEM, además de normas y guías complementarias como NEMA MS4 y MS8 para aspectos específicos de RM.
|
||||
|
||||
En resumen, la norma IEC 60601-2-33 exige que los equipos de resonancia magnética:
|
||||
|
||||
- Mantengan un funcionamiento seguro y fiable frente a perturbaciones electromagnéticas externas.
|
||||
- No generen emisiones que puedan afectar otros dispositivos en el entorno clínico.
|
||||
- Cumplan con pruebas y límites de CEM establecidos en IEC 60601-1-2.
|
||||
- Incorporen diseños que mitiguen riesgos electromagnéticos.
|
||||
- Proporcionen documentación adecuada para el uso seguro en entornos electromagnéticos.
|
||||
|
||||
Estos requisitos son fundamentales para garantizar la seguridad del paciente, del personal y la integridad del diagnóstico en entornos con múltiples dispositivos electrónicos.
|
||||
|
||||
Citations:
|
||||
[1] https://www.une.org/encuentra-tu-norma/busca-tu-norma/norma?c=N0073474
|
||||
[2] https://www.vencoel.com/como-afrontar-la-norma-en-60601-en-el-desarrollo-de-equipos-medicos/
|
||||
[3] https://eur-lex.europa.eu/legal-content/ES/TXT/HTML/?uri=CELEX%3A52004XC0624%2801%29&from=EN
|
||||
[4] https://www.denetim.com/es/laboratuvar/medikal-cihaz-testleri/ts-en-60601-2-33-elektrikli-tibbi-donanim-bolum-2-33-vucut-disi-kullanilan-tibbi-tani-amacli-manyetik-rezonans-donaniminin-guvenligi-icin-belirli-ozellikler/
|
||||
[5] https://www.eurolab.net/es/sektorel/medikal-cihaz-testleri/iec-60601-tibbi-elektrikli-ekipman/
|
||||
[6] https://www.farmacopea.org.mx/Repositorio/Documentos/971.pdf
|
||||
[7] https://www.en.aenor.com/_layouts/15/r.aspx?c=N0044560
|
||||
[8] https://m.antpedia.com/standard/sp/es/464969.html
|
||||
|
||||
---
|
||||
Answer from Perplexity: https://www.perplexity.ai/search/tengo-que-investigar-la-electr-4k7FpETaQ4OAV_WLSeULeA?utm_source=copy_output
|
||||
|
||||
----------------------------------------------------------------------
|
||||
|
||||
Los diseños de circuitos para lograr compatibilidad electromagnética (CEM) en equipos como los de resonancia magnética (RM) deben seguir varias especificaciones técnicas para minimizar emisiones no deseadas y aumentar la inmunidad frente a interferencias externas. Entre las principales recomendaciones y especificaciones se encuentran:
|
||||
|
||||
- **Minimizar bucles de corriente**: Los conductores que forman bucles grandes en la placa o cableado inducen tensiones por campos magnéticos variables, generando emisiones electromagnéticas. Por eso, el diseño debe reducir al máximo el área de estos bucles para evitar radiación EMI[1].
|
||||
|
||||
- **Uso de circuitos RLC para control de resonancias**: Los circuitos que incluyen resistencias, inductancias y capacitancias (RLC) deben diseñarse para evitar resonancias no deseadas que amplifiquen interferencias. Se busca un diseño que controle la respuesta en frecuencia y evite picos de resonancia que puedan aumentar el ruido electromagnético[2].
|
||||
|
||||
- **Blindajes y filtrados**: Incorporar blindajes metálicos conectados a tierra y filtros en las líneas de alimentación y señales para bloquear o atenuar interferencias electromagnéticas tanto emitidas como recibidas[5][6].
|
||||
|
||||
- **Diseño de PCB (placas de circuito impreso)**:
|
||||
- Mantener trazas cortas y bien apantalladas.
|
||||
- Separar señales sensibles de las fuentes de ruido.
|
||||
- Uso adecuado de planos de tierra para minimizar impedancias y acoplamientos no deseados.
|
||||
- Evitar cruces innecesarios y mantener una topología que reduzca la interferencia entre circuitos[4][8].
|
||||
|
||||
- **Selección de componentes**: Utilizar componentes con características adecuadas para CEM, por ejemplo, circuitos integrados con baja emisión y alta inmunidad, conectores y cables diseñados para minimizar interferencias[4].
|
||||
|
||||
- **Diseño sistemático desde etapas tempranas**: La compatibilidad electromagnética debe integrarse desde la fase de diseño conceptual, no solo como corrección posterior, para reducir costos y mejorar la fiabilidad del producto[4].
|
||||
|
||||
- **Control de fuentes de ruido y vías de acople**: Identificar y mitigar las fuentes internas de interferencia y los caminos por donde el ruido puede acoplarse a circuitos sensibles (acoplamiento capacitivo, inductivo o por radiación)[6].
|
||||
|
||||
En resumen, el diseño de circuitos para cumplir con CEM implica una combinación de minimizar bucles de corriente, controlar resonancias, usar blindajes y filtros, optimizar el diseño de PCB, seleccionar componentes adecuados y planificar desde el inicio para evitar interferencias electromagnéticas que afecten el funcionamiento y seguridad del equipo.
|
||||
|
||||
Estos principios son aplicables a la electrónica de máquinas de RMN para garantizar que la electrónica opere correctamente en el entorno de campos magnéticos intensos y con alta sensibilidad a interferencias.
|
||||
|
||||
Citations:
|
||||
[1] https://www.um.es/docencia/mmc/pdf/cem.pdf
|
||||
[2] https://biblus.us.es/bibing/proyectos/abreproy/92056/fichero/TFG-2056-ROLDAN.pdf
|
||||
[3] https://www.campus-virtual.mineria.unam.mx/Mineria/Cursos/Schneider/documentos/PDF_U1_EM.pdf
|
||||
[4] https://www.youtube.com/watch?v=rlrnhc2mOA4
|
||||
[5] https://www.ingenieros.es/files/proyectos/Nociones_teoricas_de_Compatibilidad_Electromagnetica.pdf
|
||||
[6] https://wiki-power.com/es/EMC%E8%AE%BE%E8%AE%A1%E6%8C%87%E5%8D%97/
|
||||
[7] http://ieb-srv1.upc.es/gieb/tecniques/doc/EMC/pdfs/emc.pdf
|
||||
[8] https://dialnet.unirioja.es/descarga/articulo/8612639.pdf
|
||||
|
||||
---
|
||||
Answer from Perplexity: https://www.perplexity.ai/search/tengo-que-investigar-la-electr-4k7FpETaQ4OAV_WLSeULeA?utm_source=copy_output
|
||||
Binary file not shown.
Binary file not shown.
Loading…
Reference in New Issue