Nuevo firmware del altímetro Nano (v1.60)

Hemos lanzado un nuevo firmware para el altímetro Nano.
Se trata principalmente de una serie de mejoras enormes, pero también resuelve algunos errores.
Le recomendamos encarecidamente que actualice a este nuevo firmware.
Puede hacerlo desde nuestra página de actualización de firmware aquí.

Aspectos destacados (más detalles abajo)

• Se corrigió el error que causaba detección tardía de burnout.
• Se calcula la aceleración compensada por arrastre.
• Ahora se admite logging de hasta 400Hz.
• Filtro Truepath actualizado de versión 1.0 a 1.2
• La detección de burnout ahora utiliza aceleración compensada por arrastre, lo que da puntos de burnout verdadero altamente precisos.
• Ignición de múltiples etapas y burnouts significativamente mejorados.
• Formato de log ACLZ v2, que proporciona 38000 muestras por vuelo y altitud bruta y presión (aumento de 24000 anteriormente)
• Fusión de velocidad en lugar de velocidad solo por presión
• Datos registrados antes del vuelo extendidos a al menos 8 segundos, aumentado desde 4 segundos
• Seguridad de detección de lanzamiento mejorada con protección adicional de tasa de cambio en la altitud de la plataforma y tiempos de validación aumentados.
• Sincronización mejorada entre IMU y presión
• Buffer de recuperación expandido de 4800 a 7200 muestras. (1:5 muestras recuperadas de hasta 38,000 muestras)
• Comunicación bidireccional a través de USB para descargar logs y aplicar configuraciones. Permitiendo una nueva página web en la nube para configurar ajustes o cargar logs con facilidad.
• Se corrigió el error donde la unidad se despertaría instantáneamente después de entrar en modo de sueño profundo después de un vuelo (¡vaya!).
• Reparación de altitud mediante comparación de aceleración para errores de presión en el vuelo inicial que causan corrupción de altitud.
• El altímetro firma un log CSV o ACLZ convertido independientemente del formato elegido para permitir una conversión exacta entre formatos en el sitio web sin exponer la clave de firma.

Error causando detección tardía de burnout

Esto fue causado por el hecho de que la detección de lanzamiento puede tomar hasta 2500ms (típicamente más rápido) para validarse. El sistema de detección de burnout entonces solo se ejecutaba desde este punto y perdía burnout que ocurrió antes.
La solución es buscar hacia atrás en el log guardado para burnout(s) en caso de que el burnout ya haya ocurrido cuando se detecta el lanzamiento.

Aceleración compensada por arrastre e implicaciones de burnout

Uno de los problemas principales que notamos con la detección de burnout es en vuelos de mayor velocidad. Determinar cuándo el empuje realmente se detuvo en una forma cruda simplemente busca un cambio en la dirección de la aceleración.
Sin embargo, esto es realmente una medida de cuándo el arrastre excede el empuje, y no cuándo el empuje ha cesado.
Al utilizar la fase de costa de un vuelo, podemos estimar un coeficiente de arrastre y la fuerza de arrastre en el cohete, permitiendo una detección de burnout mucho más precisa y la cantidad de empuje actualmente aplicado al cohete.
El resultado es una traza clara de empuje o no empuje que es fácil de determinar los puntos de quemado y burnout.
Para el Nano, esto encaja perfectamente con su post-procesamiento de los datos de vuelo cuando se guarda el log. Para detección en vivo, otros altímetros aún dependen del cambio de signo y luego refinan ese momento cuando ocurre la costa.

Este gráfico muestra la diferencia significativa entre el cambio de signo del vector de aceleración y la detección de empuje compensada por arrastre del burnout.

Logging de datos 400Hz

Esto se aplica a Nanos con el sensor IMU (revisión 4+), la configuración predeterminada ahora es 400Hz con relación híbrida de 8.
Esto significa que el Nano grabará a 50Hz en el buffer previo al vuelo antes de pasar a 400Hz para el lanzamiento hasta 5 segundos después del apogeo.
Luego baja a 400/8 con modo híbrido (50Hz) hasta que esté dentro de 20m de la altitud de aterrizaje donde vuelve a subir.
El Nano aún puede manejar vuelos largos ajustando la configuración según sea necesario, y aún podrá grabar durante 3-4 minutos incluso con 400Hz y modo híbrido habilitados.


Diagrama de cómo funciona el modo híbrido.

Los eventos violentos que producen fuerzas G significativas también restablecerán la resolución a 400Hz más allá de lo que se muestra en la imagen anterior.

Versión 1.2 de Truepath

Nuestro filtro Truepath ha sido actualizado como parte de nuestro trabajo en el Jupiter y lo hemos llevado al Nano.
Desde la perspectiva del usuario, no ha cambiado mucho, la ruta se ajustará ligeramente mejor a datos extremadamente ruidosos, aunque la mayor parte del trabajo se ha enfocado hacia el extremo más ruidoso/violento de la escala de vuelos.
También tiene un nuevo límite en sus ventanas de reparación, si se alinean espalda con espalda, para prevenir la posibilidad de que porciones extremadamente largas de un vuelo necesiten ser reparadas sin suficientes datos a lo largo del intervalo.

Detección de burnout e ignición de múltiples etapas

Con la adición de la aceleración compensada por arrastre, también podemos detectar mejor múltiples etapas.
Hacemos esto de dos formas: una el punto de fin de empuje estándar (definido como < 0.2g de empuje) y también detectando firmas de estadificación que no necesariamente dejan de empujar entre ellas.

Formato de log ACLZ v2 y almacenamiento adicional

El formato de log ACLZ (Altimeter cloud log) es un paso gigantesco hacia adelante para nuestros altímetros. Ahora es el formato predeterminado en nuestros altímetros a medida que se implementan nuevos firmwares.
Este formato le ahorra entre 15 y 25 veces el almacenamiento que usa un archivo CSV, sin embargo, ni un solo bit de datos se pierde. ¡Sigue estando allí!

El límite de vuelo del Nano fue restringido por el tamaño de un CSV que solo podía almacenar un único CSV de 24,000 muestras. Ahora puede almacenar 10-14 logs de vuelo de tamaño completo de 38000 muestras en el Nano, y para vuelos típicos se debería lograr el límite de 50 logs de vuelo. Si bien no puede leer un log ACLZ como un CSV fácilmente, puede cargarlos en nuestro sitio web y descargar un CSV desde el sitio web. Esto significa que puede beneficiarse del límite de muestras adicionales y ahorros de almacenamiento en el dispositivo y aún así obtener un CSV cuando lo necesite.

Los archivos ACLZ no solo le dan más muestras, sino que también permiten que la presión bruta y la altitud bruta se almacenen como conjuntos de datos adicionales que no se podían ajustar antes. ACLZ es un log de vuelo binario firmado con Ed25519, codificado en delta, comprimido con LZMA, que lleva el registro de muestra completo.

Como el Nano tiene 2.5MB de RAM nos estamos acercando a los límites de lo posible en un único flujo de compresión en 38,000 muestras, pero intentaremos y exprimir un poco más optimizando en el siguiente firmware.

Fusión de velocidad

El Nano anteriormente usaba solo presión para generar su velocidad. Esto tiene bastantes defectos ya que hay muchas formas en que picos de presión pueden ocurrir durante el lanzamiento y vuelo que corrompieron la velocidad.
Los acelerómetros pueden ofrecer velocidad, sin embargo, esto acumulará deriva con el tiempo y también no es completamente confiable.
La solución, por lo tanto, es una fusión que usa ambos. El Nano aún usa presión como su señal principal y luego tiene una confianza variable en el acelerómetro dependiendo de si ha detectado un problema de presión para superar el evento y mantener la velocidad precisa. La aceleración no se usa cuando el cohete vuela con presión precisa no corrompida.

Ejemplo que muestra una altitud bruta corrompida al inicio de un lanzamiento y la velocidad presión anterior corrompida por ella.
La línea azul es la nueva velocidad fusionada que ahora es correcta.

Log previo al vuelo extendido

El buffer previo al vuelo ha sido extendido a al menos 8 segundos a velocidad completa. En la práctica con eMode esto puede ser mucho más largo.
Ahora guardamos el tiempo adicional de 4 a 8 segundos a un máximo de 50Hz en su log de vuelo permitiéndole ver un poco más sobre las condiciones previas al lanzamiento.
La altitud del piso también ha sido movida hacia atrás a -4 a -8 segundos de -2.5 a -4 segundos para permitir un período de detección de lanzamiento más largo.

Detección de lanzamiento

Hemos aumentado el tiempo de verificación con aceleración de 500 a 1000ms, y el período sin aceleración a 2500ms. Esto se puede hacer de manera segura como resultado de los buffers previos al vuelo aumentados.
La tasa de cambio de altitud de almohadilla/piso también se ha implementado completamente. Esto evita que el promedio de presión base cambie más rápido de 2.5 metros por segundo y ayuda a evitar que eventos de vacío o eventos de presión corrompan la presión del piso cuando coloca un cono de nariz o lo quita.

Comunicación USB

El Nano ahora puede ser controlado a través de ciertos navegadores web en PCs y Laptops (navegadores Google Chrome, Microsoft Edge y Opera).
Esto permite a los usuarios hacer clic en conectar y usar el configurador de ajustes del Nano sin necesidad de editar el archivo de texto en el dispositivo. También puede cargar vuelos con un clic en lugar de tener que localizar el archivo físico en la unidad USB del Nano.

Ejemplo de la página de carga del cargador de log del altímetro directo a través de USB.


Captura de pantalla de la página Configurar ajustes a través de USB, puede acceder aquí (a través de la página de herramientas)

Error de despertar

Esto afectó el comportamiento posterior al vuelo cuando seleccionó entrar en modo de sueño profundo después de 4 o 10 minutos después del aterrizaje.
El temporizador de sueño del ciclo de muestra seguía configurado cuando se solicitaba el sueño profundo. El resultado fue que se despertó directamente del sueño profundo después de unos pocos milisegundos.
Esto hizo que pareciera que el dispositivo nunca iba a dormir como se solicitó.

Reparación de altitud mediante comparación de aceleración.

En la ignición del motor, el sensor de presión tiene un trabajo difícil: la pluma lava el área de lanzamiento y el barómetro registra un cambio de presión atmosférica que no ocurrió, lo que aparece como altitud. En algunos vuelos esto aparece como un pico o hundimiento alrededor del despegue, ocasionalmente uno grande, en un vuelo de prueba casi veinte metros de altitud que nunca fue volada. El acelerómetro no ve nada de esto, porque nada se movió realmente de esa manera, y ese desacuerdo es todo el principio de la reparación: durante el vuelo temprano el acelerómetro es prueba de que la pluma no puede engañar.

El método es deliberadamente conservador. Mientras el acelerómetro certifica que el cohete sigue en la plataforma, cualquier excursión de altitud es por definición un error de presión y la traza mantiene el nivel de la plataforma, aunque la deriva normal de la plataforma se deja exactamente como se midió. Una vez que comienza el movimiento real, el altímetro integra el acelerómetro para saber aproximadamente dónde debe estar el cohete, y utiliza esa trayectoria como un detector de mentiras en lugar de una pluma: la presión solo se considera falsa cuando se desvía más de la ruta esperada que la mitad del ascenso mismo, una barra que escala con el vuelo para que los datos genuinos nunca puedan dispararla. Un tramo condenado se reconstruye entonces usando la forma del acelerómetro para la curva, pero anclado en ambos extremos a muestras de presión reales, por lo que la reparación solo puede interpolar entre datos medidos, nunca inventar una línea propia. Todo el mecanismo se detiene poco después del burnout, mucho antes del apogeo, donde el barómetro está de nuevo a cargo exclusivo, y cada log reparado mantiene su columna de altitud bruta para que la medición original siempre esté ahí para comparar. En validación en dieciséis vuelos registrados, solo el vuelo corrompido por la pluma fue alterado; cada vuelo limpio pasó sin cambios.

Ejemplo de la reparación de la corrupción de presión temprana en un log de vuelo de muestra.

Firmas de log dual

Los logs de vuelo del Nano están firmados criptográficamente en el altímetro en el momento en que se guardan. La verificación en Altimeter Cloud prueba que un log es genuino e intacto: cambie un único valor y falla. La clave de firma nunca abandona su dispositivo, que es el punto completo, nuestros servidores pueden verificar un log pero nunca pueden crear la firma para uno, por lo que una firma válida significa una única cosa: estos datos vinieron de este altímetro, exactamente como se registraron.

Con ambos formatos CSV y ACLZ ahora compatibles, esa garantía tenía una brecha. Su dispositivo guarda un formato, y cuando el sitio web lo convirtió al otro para descarga, la conversión fue honesta pero sin firmar, porque el sitio web no puede firmar nada. Desde firmware 1.60 el altímetro cierra la brecha él mismo: en guardar calcula y firma ambas representaciones del vuelo, almacena el formato que haya configurado, y registra ambas firmas junto con él. Cuando Altimeter Cloud produce el formato alternativo, adjunta la firma que su altímetro ya hizo para exactamente esos datos. Si cada valor coincide, y lo hará a menos que algo haya sido alterado, ambos formatos se verifican. La misma protección, ambas descargas, firmadas por nada más que su altímetro.