docs.facundoitest.space

Para transmitir datos entre los dispositivos se usa una trama de 96 bits.

El frame se interpreta de esta manera:

   x   |   x      x      x      x   |    x      x      x      x    |   x      x      x
[Ctrl] | [pA1]  [pA2]  [pA3]  [pA4] |  [pB1]  [pB2]  [pB3]  [pB4]  | [pC1]  [pC2]  [pC3]

• 1 byte de control
• 4 bytes del payload A
• 4 bytes del payload B
• 3 bytes del payload C

Si bien el payload es genérico, según el byte de control los payload pA; pB y pC adquieren distintas funciones.

En cada dispositivo hay un switch case que procesa este byte y dependiendo del contenido, decide cómo procesar la carga de la trama.

Esta trama proviene del gateway, hay que probar a qué dispositivo iba dirigida. Para esto solamente es necesario comparar los 32 bits del payload B (pB) con el identificador único (devID) del dispositivo receptor.

 0000 |  x    x    x    x  | id0  id1  id2  id3 |  x    x    x
[Ctrl]|[pA1][pA2][pA3][pA4]|[pB1][pB2][pB3][pB4]|[pC1][pC2][pC3]

A station just sent a packet to the server. We should ignore it.

Another station is broadcasting its 32 bit ID string, attempting to register itself in a gateway with its ID.

Reforzar las líneas de GND, tanto del STM como de las Orange. Sin la masa extra se desconecta aleatoriamente.

La señal de entrada es la salida del mezclador de RF, después de acondicionar la amplitud a Vmax < 5v, la señal recibida tiene la particularidad que cuando no hay objetos en movimiento, el mezclador devuelve la portadora modulada de forma aleatoria (o al menos no es consistente como cuando hay un objetivo).

Por lo tanto se implementó por código un filtro, para únicamente tomar como válidas las lecturas de objetos en movimiento y de alguna forma descartar el ruido del radar en “reposo”.

La lógica es la siguiente, tipo autocorrelador de medias-longitudes de onda:

1. Entra en un bucle for de n repeticiones
2. con dos o más bucles while se detectan los pulsos de la señal de entrada
   1. se incrementa un contador durante un nivel alto de la señal
   2. el valor corresponde al tiempo que se mantiene el nivel alto
   3. se introduce una espera, actualmente tiene hardcodeados 20 ms
   4. el bucle corre nuevamente y guarda el valor del contador en otra variable
3. se comparan los valores más alto y más bajo de los que fueron capturados, para obtener el jitter de la señal

El código:

  while (1){
 
 
 		/*
 		 * ##############################################
 		 * 			CHECK FOR TIME CONSISTENCY
		 * ##############################################
		 * NO SÉ QUÉ MIERRRRDA HICEEEEEEEEEEEEEEEEE 😅😅😅😅😅😅
		 * podría tener dos variables auxiliares
		 * auxA y auxB
		 * espero al nivel alto/bajo
		 * incremento auxA mientras dure el nivel
		 * espero los 20ms y espero que termine el nivel donde caí
		 * cuento de vuelta incrementando auxB con el ancho del puso
		 * comparo A - B las veces que haga falta, mientras no me pase del 1000ms
		 * también puedo usar un acumulador y la otra variable que sume un semiciclo y reste al siguiente
		 * si están dentro de cierto límite, los pulsos son parecidos y puedo estimar que es una lectura válida
		 * lo que estaría bueno, sería ponerle nombres un poco más descriptivos a las variables
		 * por ej que una variable auxiliar o temporal se llame aux o temp
		 * el minimo se llame min, el mázimo max, etc. No a, b, c, c_0, a_2, _aux0, etc
		 * lo que hace es correr nsteps veces un bucle y guarda el ancho del pulso
		 * en un array de nsteps elementos, después compara todos y guarda el más grande
		 * contra el más chico, de esa forma sabe si es tolerable la variación
		 */
 
	  while(!HAL_GPIO_ReadPin(GPIOB, RADAR_Pin));
	  // espera un nivel alto, para saber el contexto inicial
	  for(i=0; i < nsteps; i++){
 
		  //_delayUsec(50); // qué poronga hace este delay??... chau
		  //AFUERA
 
		  	/*
			 * HIGH LEVEL ...‾‾‾‾‾‾‾‾...
			 */
		  while(HAL_GPIO_ReadPin(GPIOB, RADAR_Pin)){
			  // aumenta un contador int de 16 bits inicializado en 0 mientras dure el pulso alto
			  // mentira, solamente espera que el valor deje de ser 1
		  }
 
 
		  // acá si salió del while significa que llegó el final del pulso
 
		  // acá espera la friolera de 20 ms (a 1 kHz son 20 pulsos)
		  // tampoco sé para qué hace esto 😅
		  // aaaacá está la papa, auxA tiene el ancho del pulso alto en algún momento
		  // si lo guardo y comparo con el ancho de un pulso 20 ms después,
		  // me debería mostrar la consistencia entre anchos de 2 pulsos aleatorios del tren de pulsos
		  // si este delay lo pongo al principio no tengo que resincronizarme con los pulsos
		  HAL_Delay(20);
 
			/*
			 * FALLING EDGE ‾‾‾‾|_____
			 * qué pasa si cae en un nivel alto después del delay de 20ms?? gg
			 * bueno, espero un par de pulsos más, así lo agarro completo
			 */
		  while(HAL_GPIO_ReadPin(GPIOB, RADAR_Pin));
		  while(!HAL_GPIO_ReadPin(GPIOB, RADAR_Pin));
 
		  while(HAL_GPIO_ReadPin(GPIOB, RADAR_Pin)){
			  // acá una vez que empieza un nivel alto aleatorio, aumenta el valor de un entero de 16 bits
			  // en el array de contener intentos
			  _A_n[i]++;
		  }
 
			/*
			 * FALLING EDGE ‾‾‾|___
			 * en este punto ya tengo dos variables (A y B) con el largo de pulsos separados 20 ms uno del otro
			 * mentira, tengo el ancho del pulso del enésimo bucle for
			 */
		  // necesito guardar el más grande (A) y el más chico (B) y sacar la diferencia (0)
		  if(i == 0){
			  /* para la primera vuelta, el máximo y el mínimo son lo mismo
			   * 
			   */
			  auxA = _A_n[0];
			  auxB = _A_n[0];
		  }
 
		  if(_A_n[i] > auxA){
			  // ahora, si esta vuelta es más grande que auxA, guardo en auxA
			  auxA = _A_n[i];
		  }
 
		  if(_A_n[i] < auxB){
			  // pero si esta vuelta es más chica que auxB, guardo en auxB
			  auxB = _A_n[i];
		  }
 
	  } // end FOR
	  /*
	   * me interesa saber la diferencia entre el más grande y el más chico
	   * ya que esa diferencia es el fucking jitter, calculado de forma directa!
	   *
	   */
 
	  aux0 = auxA - auxB;
 
	  /*
	   * otra cosa que me interesa es el valor medio de aux0 en el tiempo
	   * dice cuánto se incrementa el jitter
	   * puedo hacer mean = (aux0(n) + mean)/2
	   */
 
	  meanJitter = (aux0 + meanJitter)/2;
 
 
	  //ToDo: hacer configurable maxjitter y nsteps
	  // hacer que desde alguna parte pueda poner los valores y un "send" para establecerlos
	  // revisar los docs
 
	  if(aux0 < maxJITTER){ // y si el resultado está dentro de lo permitido...
 
		  // puedo tomar el tiempo T que demoran n pulsos
		  // GetTick() se configura automáticamente con hal init
		  // https://stackoverflow.com/questions/42747128/does-hal-gettick-return-ticks-or-milliseconds-and-how-to-measure-in-microsec
 
		  timerTick_0 = HAL_GetTick();
 
		  for(i=0; i<(100*nsteps); i++){
		  	  while(HAL_GPIO_ReadPin(GPIOB, RADAR_Pin));
		  	  while(!HAL_GPIO_ReadPin(GPIOB, RADAR_Pin));
		  }
 
		  // T_00ms contiene los ms x100 de cada pulso
		  // o sea T_00ms == 100 significa que cada periodo fue de 1 ms
		  // después se implementa la matemática para pasar de T a velocidad
		  // la frecuencia mucho no me sirve, pero sería (100/T_00ms)x10³
		  T_00ms = (HAL_GetTick() - timerTick_0)/nsteps;
 
	  }
	  else{
		  T_00ms = 0;
	  }
 
   }
    /* ##################################################
     *
     *              USER CODE END WHILE
     *
     * ##################################################
     * */
 
    /* USER CODE BEGIN 3 */
 
 
  /* USER CODE END 3 */
}

Palabras clave
Dedicatoria y agradecimientos
Resumen
Abstract
Índice de Figuras
Índice de Tablas

1. Introducción
1.1 Contexto temático
1.2 Definición del problema
1.3 Motivación
1.4 Objetivos
1.4.1 Objetivo general
1.4.2 Objetivos específicos
1.5 Contribución esperada y alcance
1.6 Metodología

2. Marco teórico
2.1 Internet de las cosas (IoT)
2.1.1 ¿Qué es IoT o ‘Internet de las cosas’?
2.1.2 IoT Industrial	
2.2 Bases de Datos
2.2.1 Redis
2.2.2 InfluxDB
2.3 STM32
2.3.1 STM32F103
2.4 Arquitectura ARM
2.4.1 H3 Quad-core Cortex-A7
2.4.2 Linux sobre Plataformas ARM
2.5 Lenguajes de programación
2.5.1 Lenguaje C
2.5.2 Python en Sistemas Embebidos
2.6 Radar Doppler Microondas
2.6.1 Generalidades
2.6.1.1 Introducción, Principios Básicos y Características Generales	
2.6.1.2 Radar Doppler
2.6.1.3 Bandas de Radiofrecuencia y Aplicaciones
2.6.1.4 Bandas I/J (Radares de Banda X y Ku)
2.6.1.5 Implementación del radar Doppler
2.6.2 Uso en metrología legal
2.6.3 Filtrado Analógico
2.6.4 Filtrado Digital
2.6.4.1 Filtrado por Autocorrelación

3. Diseño
3.1 Diseño del Sistema
3.1.1 Diagrama General del Sistema Propuesto
3.1.2 Selección de Dispositivos de Cómputo (MCUs y CPUs)
3.1.2.1 Selección de los microcontroladores
3.1.2.2 Selección de los CPU para los gateways
3.1.3 Selección de Sensores y Periféricos
3.1.4 Selección de Software
3.1.5 Diseño del Endpoint
3.1.6 Diseño del Gateway
3.1.7 Diseño de la Aplicación Web

4. Implementación
4.1 Enfoque y metodología
4.2 Implementación del Endpoint
4.2.1 Implementación del contador de frecuencia y filtrado
4.2.1.1 Contador de frecuencia
4.2.1.2 Filtrado
4.2.2 Implementación de las comunicaciones
4.2.3 Display
4.2.4 Acondicionamiento de la entrada de señal del radar
4.3 Implementación del Gateway
4.4 Implementación de la aplicación web

5. Pruebas
5.1 Optimización del filtro autocorrelador
5.1.1 Mediciones en reposo / solo ruido de fondo
5.1.2 Mediciones de la señal de calibración
5.1.3 Costo computacional de leer el GPIO
5.2 Pruebas de interferencia
5.3 Simulación con un generador de señales
5.4 Pruebas sobre vehículos

6. Análisis de Resultados Experimentales y Discusión

7. Conclusiones
7.1 Recomendaciones para versiones futuras

Bibliografía

Anexo A: Bucle infinito del endpoint
Anexo B: Callbacks del MCU
B.1 Interrupción del temporizador
B.2 Interrupción DMA (Buffer UART Rx)
Anexo C: Bucle infinito del gateway

Comienza con una historia o anécdota que conecte emocionalmente con la audiencia.

Introducción y motivación Creo que en mi vida no le he dedicado más tiempo a algún proyecto que a este. La idea detrás de este proyecto se basa en la percepción vs. la realidad de la velocidad al conducir. Por ejemplo, cuando manejamos no estamos constantemente mirando el velocímetro. Después de horas en una autopista a 120 km/h, es fácil entrar a un pueblo y seguir yendo a 60 km/h sin darse cuenta. Este fenómeno es común. El proyecto busca ayudar a los conductores a ser conscientes de su velocidad real y no solo de la percibida.

Qué sucede si uno va por un camino y de pronto ve un cartel luminoso que muestra la velocidad que llevás? 🤔. Pueden pasar dos cosas, o te das cuenta que vas más rápido de lo que pensabas, tal vez vas bien o lo usás para organizar con la gente del barrio un torneo para ver quién pasa más rápido (hay estudios sobre esto). Sin embargo, es probable que la mayoría ajuste su conducción para ir más despacio. Esta simple retroalimentación puede hacer una gran diferencia en la seguridad vial, especialmente en zonas urbanas o críticas.

—

Introduce tu solución sin entrar en demasiados detalles técnicos, centrándote en cómo mejora la situación.

La Solución

El proyecto se basa en desarrollar un sistema que mida la velocidad de los vehículos utilizando un radar Doppler microondas y que muestre esa información en tiempo real, o con un delay muy corto, en una pantalla LED. Los datos también se almacenan para análisis futuros,dado que el costo de implementar esta característica es relativamente bajo y da la posibilidad de entender mejor los patrones de velocidad y a implementar medidas de seguridad y reglas de tránsito más efectivas y adecuadas. Lo interesante es que se tuvo en cuenta la escalabilidad del sistema, la primera versión no soporta múltiples sensores y 'endpoints', pero la trama de comunicaciones y el manejo de los datos está pensado para mantener cierta simplicidad, a la vez que contempla evitar un rediseño muy grosero del sistema en el caso que se agreguen puntos de control, radares, endpoints, como le quieran llamar. Por qué un radar Doppler? Bueno, tiene varias ventajas, sobre todo si uno piensa en las alternativas: tubos neumáticos que se gastan, ultrasonido que falla con clima adverso, loops inductivos o placas piezoeléctricas que requieren levantar el pavimento para instalarlos. En línea con esta búsqueda de optimización de la solución, se investigaron soluciones comerciales disponibles. Las cuales hay bastantes, no muchisimas, pero se consiguen, son un poco caras, eso sí, y lo que no me convencía es que es todo bastante opaco y enlatado, por lo cual quería que el diseño sea lo más económico, modular y escalable, sin perder de vista la capacidad de medir la velocidad, que es el objetivo principal.

—

Enfatiza los beneficios de tu proyecto de manera que el público pueda ver su valor.

Beneficios e impacto

Estos sistemas de retroalimentación dinámica y en tiempo real de la velocidad están probados que disminuyen, en promedio, unos 8 Km/h la velocidad en una zona. En el percentil 75, se disminuye en promedio 11 Km/h. Teniendo en cuenta que con la velocidad aumenta casi de forma exponencial la gravedad de las lesiones ante un choque, en el largo plazo, implementar los indicadores ayuda a hacer más seguras ciertas zonas críticas, como túneles, puentes, curvas pronunciadas y zonas urbanas o con animales.

—

Ofrece una breve vista previa de lo que cubrirás en la presentación.

Diseño e implementación

En las próximas diapositivas les cuento, a grandes rasgos, sobre cómo funciona el sistema, los componentes clave que utilizamos, los resultados obtenidos hasta ahora en esta primera versión y cómo este proyecto puede crecer y adaptarse en el futuro.

«acá hablo sobre los componentes y algoritmos utilizados»

—

Reflexiones sobre IoT

En el universo de los artefactos y soluciones basadas en IoT, uno investigando se encuentra que la simplicidad del concepto se ve afectada por el nombre: conectar cosas a Internet. A grandes rasgos, IoT pretende dotar de cierta inteligencia a objetos cotidianos, como una cafetera, por ejemplo, conectándola a un cronómetro o un timer para así garantizar café a la mañana (o a un horario en particular). Aunque la definición del problema y la solución son claras (obtener café a tal hora), la implementación, al entrar en el universo IoT, implica la inserción de microcontroladores, código y conexiones inalámbricas en dispositivos cotidianos para permitir su programación, habiendo podido, probablemente, lograr el mismo objetivo con una complejidad menor del sistema. Este sobredimensionamiento de soluciones, si bien facilita la comunicación y colaboración entre dispositivos; y con algo de suerte y buenos criterios de diseño, mejora la escalabilidad de los sistemas, también aporta retos significativos. Aparecen dos potenciales problemas: la seguridad del dispositivo y la percepción de valor del usuario.

Desde la perspectiva de la Seguridad, el historial de la industria de IoT no es el mejor, lo cual, tanto en entornos personales como industriales, genera cierta inquietud sobre la seguridad y protección de los datos. La conectividad generalizada, aunque resulta prometedora, también abre la puerta a posibles abusos, un tema que ha sido subrayado con preocupación en algunos sectores (industriales y de la salud, por ejemplo).

La reflexión sobre IoT del ámbito hogareño (el consumer grade) viene a que la etiqueta “inteligente” aplicada a IoT muy a menudo se traduce en la capacidad de operar un dispositivo mediante una aplicación móvil. En muchos casos, esto implica una implementación compleja de una simple conectividad inalámbrica, ofreciendo finalmente una utilidad bastante limitada en comparación con las expectativas generadas en el consumidor por la etiqueta de ser un artefacto “inteligente”.

Criterios de diseño y sobredimensionamiento

Un principio fundamental en el diseño es que la solución más simple suele ser la más adecuada. Sin embargo, existe una tendencia a diseñar pensando en las características y capacidades de la tecnología que queremos usar, habilitando e instalando todo lo posible y agregando funciones “por las dudas”. A medida que el producto madura, este enfoque suele requerir una limpieza del diseño para eliminar la complejidad innecesaria y centrarse en la funcionalidad esencial. Reid Hoffman, fundador de LinkedIn dijo que “si no te avergüenza la primera versión de tu producto, entonces lo lanzaste demasiado tarde”.

El diseñador Dieter Rams (some german motherfucker) también enfatizaba que “el mejor diseño es el menor diseño posible”. Estos conceptos subrayan la importancia de la simplicidad y la funcionalidad sobre la complejidad innecesaria. En mi experiencia, he visto sitios web, por ejemplo, con implementaciones demasiado complejas, como un caso específico donde había dos ambientes (Dev/QA y Producción) con múltiples contenedores, pero los desarroladores y los que mantenían el sitio nunca se pusieron de acuerdo en cómo hacer los pases a Producción, entonces los cambios se realizaban directamente en el almacenamiento de Producción en Azure. Había un servicio de frontdoor y una CDN para un sitio que era solo un formulario y contenido estático. Este es un claro ejemplo de los males del sobredimensionamiento de soluciones. La simplicidad no solo mejora la eficiencia, sino que también facilita el mantenimiento y la seguridad del sistema.