Nouveau firmware d'altimètre Nano (v1.60)

Nous avons publié un nouveau firmware pour l'altimètre Nano.
Il s'agit principalement d'une suite d'améliorations considérables mais qui résout également quelques bugs.
Nous vous suggérons fortement de mettre à jour vers ce nouveau firmware.
Vous pouvez le faire à partir de notre page de mise à jour du firmware ici.

Points clés (plus de détails ci-dessous)

• Bug causant une détection de burnout tardive corrigé.
• Accélération compensée par la traînée calculée. 
• Enregistrement jusqu'à 400Hz maintenant supporté.
• Filtre Truepath mis à jour de la version 1.0 à 1.2
• La détection de burnout utilise maintenant l'accélération compensée par la traînée donnant des points de burnout vrai hautement précis.
• L'allumage multi-étages et les burnouts considérablement améliorés.
• Format de log ACLZ v2, donnant 38000 échantillons par vol et altitude brute et pression (augmentation par rapport aux 24000 précédents)
• Fusion de vélocité au lieu de vélocité basée sur la pression uniquement
• Données enregistrées en pré-vol étendues à au moins 8 secondes au lieu de 4 secondes
• Sécurité de la détection de lancement améliorée avec la protection supplémentaire du taux de variation sur l'altitude au sol et les temps de validation accrus.
• Synchronisation IMU à pression améliorée
• Buffer de récupération étendu de 4800 à 7200 échantillons. (1:5 échantillons récupérés jusqu'à 38 000 échantillons)
• Communication bidirectionnelle via USB pour télécharger les logs et appliquer les paramètres. Activation d'une nouvelle page web cloud pour configurer les paramètres ou télécharger les logs facilement.
• Bug corrigé où l'unité se réveillait instantanément après être entrée en veille profonde après un vol (oups !)
• Réparation de l'altitude via comparaison d'accélération pour les erreurs de pression en début de vol causant la corruption de l'altitude. 
• L'altimètre signe un log CSV ou ACLZ converti indépendamment du format choisi pour permettre une conversion ultérieure exacte entre les formats sur le site web sans exposer la clé de signature. 

Bug causant une détection de burnout tardive

Ceci était causé par le fait que la détection de lancement peut prendre jusqu'à 2500ms (généralement plus rapide) pour valider. Le système de détection de burnout ne s'exécutait alors que à partir de ce moment et ratait le burnout qui s'était déjà produit avant.
La solution est de regarder en arrière dans le log sauvegardé pour chercher les burnouts si le burnout s'est déjà produit quand le lancement est détecté.

Accélération compensée par la traînée et implications sur le burnout

L'un des principaux problèmes que nous avons remarqués avec la détection de burnout est sur les vols à plus haute vitesse. Déterminer quand la poussée avait réellement cessé sous une forme brute cherche simplement un changement dans la direction de l'accélération.
C'est en réalité une mesure de quand la traînée dépasse la poussée, et non quand la poussée a cessé.
En utilisant la phase de coasting d'un vol, nous sommes en mesure d'estimer un coefficient de traînée et la force de traînée sur la fusée, permettant une détection de burnout beaucoup plus précise et la quantité de poussée actuellement appliquée à la fusée.
Le résultat est une trace claire de la poussée ou non qui est facile à déterminer à partir des points de combustion et burnout. 
Pour le Nano, cela s'adapte parfaitement au post-traitement des données de vol quand le log est sauvegardé. Pour la détection en direct, les autres altimètres s'appuient toujours sur le changement de signe puis affinent ce moment quand le coasting se produit.

Ce graphique montre la différence significative entre le changement de signe du vecteur d'accélération et la détection de burnout de la poussée compensée par la traînée.

Enregistrement de données à 400Hz

Cela s'applique aux Nanos avec le capteur IMU (révision 4+), le paramètre par défaut est maintenant 400Hz avec un rapport hybride de 8.
Cela signifie que le Nano enregistrera à 50Hz dans le buffer pré-vol avant de passer à 400Hz au lancement jusqu'à 5 secondes après l'apogée.
Il baisse ensuite à 400/8 avec le mode hybride (50Hz) jusqu'à 20m de l'altitude d'atterrissage où il remonte à nouveau.
Le Nano peut toujours gérer les vols longue durée en ajustant les paramètres selon vos besoins, et vous pourrez toujours enregistrer pendant 3-4 minutes même avec 400Hz et le mode hybride activés. 


Diagramme montrant comment fonctionne le mode hybride.

Les événements violents qui produisent des forces G significatives restaureront également la résolution à 400Hz au-delà de ce qui est montré dans l'image ci-dessus.

Truepath version 1.2

Notre filtre Truepath a été mis à jour dans le cadre de notre travail sur Jupiter et nous l'avons amené au Nano.
Du point de vue de l'utilisateur, pas grand-chose n'a changé, le chemin s'adaptera légèrement mieux aux données extrêmement bruitées et la plupart du travail s'est concentré sur l'extrémité des vols plus bruyants/violents.
Il a également une nouvelle limite sur ses fenêtres de réparation, s'ils s'alignent dos à dos, pour éviter la possibilité que d'extrêmement longues portions d'un vol aient besoin d'être réparées sans assez de données tout au long de la portée. 

Détection de burnout et allumage multi-étages

Avec l'ajout de l'accélération compensée par la traînée, nous sommes également en mesure de mieux détecter les multi-étages.
Nous le faisons de deux façons, d'une part le point de fin de poussée standard (défini comme < 0.2g de poussée) et aussi en détectant les signatures d'étagement qui ne s'arrêtent pas nécessairement de pousser entre elles.

Format de log ACLZ v2 et stockage supplémentaire

Le format de log ACLZ (Altimeter cloud log) est un énorme progrès pour nos altimètres. C'est maintenant le format par défaut sur nos altimètres à mesure que les nouveaux firmwares se déploient.
Ce format vous fait économiser entre 15 et 25 fois le stockage qu'un fichier CSV utilise, cependant pas un seul bit de données n'est perdu. C'est tout toujours là !

La limite de vol du Nano était limitée par la taille d'un CSV, il ne pouvait stocker qu'un seul CSV de 24 000 échantillons. Vous pouvez maintenant stocker 10-14 logs de vol de taille complète à 38 000 échantillons sur le Nano, et pour les vols typiques, jusqu'à la limite de 50 logs de vol devrait être réalisable. Bien que vous ne puissiez pas lire un log ACLZ comme un CSV facilement, vous pouvez les télécharger sur notre site web et télécharger un CSV à partir du site web. Cela signifie que vous pouvez bénéficier de la limite d'échantillons supplémentaires et des économies de stockage sur l'appareil et toujours obtenir un CSV quand vous en avez besoin. 

Les fichiers ACLZ vous donnent non seulement plus d'échantillons mais permettent également à la pression brute et à l'altitude brute d'être stockées comme ensembles de données supplémentaires qui ne pouvaient pas tenir avant. ACLZ est un log de vol binaire signé Ed25519, compressé LZMA, codé par delta, portant l'enregistrement complet des échantillons.

Puisque le Nano a 2.5MB de RAM, nous nous approchons des limites de ce qui est possible dans un seul flux de compression à 38 000 échantillons, mais nous essayerons de presser un peu plus en optimisant dans le prochain firmware.

Fusion de vélocité

Le Nano utilisait précédemment uniquement la pression pour générer sa vélocité. Cela a pas mal de défauts car il y a beaucoup de façons que les pics de pression peuvent se produire pendant le lancement et le vol qui ont corrompu la vélocité.
Les accéléromètres peuvent offrir une vélocité, cependant cela s'accumulera à la dérive au fil du temps et n'est également pas complètement fiable.
La solution, par conséquent, est une fusion qui utilise les deux. Le Nano utilise toujours la pression comme signal primaire et a alors une confiance variable sur l'accéléromètre selon s'il a détecté un problème de pression pour surmonter l'événement et maintenir une vélocité précise. L'accélération n'est pas utilisée quand la fusée vole avec une pression précise non corrompue.

Exemple montrant une altitude brute corrompue au début d'un lancement et l'ancienne vélocité de pression étant corrompue par elle.
La ligne bleue est la nouvelle vélocité fusionnée qui est maintenant correcte.

Log pré-vol étendu

Le buffer pré-vol a été étendu à au moins 8 secondes à plein débit. En pratique avec eMode, cela peut être beaucoup plus long. 
Nous sauvegardons maintenant le temps supplémentaire de 4 à 8 secondes à un maximum de 50Hz dans votre log de vol vous permettant de voir un peu plus sur les conditions pré-lancement.
L'altitude du sol a également été déplacée en arrière de -4 à -8 secondes de -2.5 à -4 secondes pour permettre une période de détection de lancement plus longue.

Détection de lancement

Nous avons augmenté le temps de vérification avec l'accélération de 500 à 1000ms, et la période sans accélération à 2500ms. Cela peut être fait en toute sécurité grâce aux buffers pré-vol augmentés.
Le taux de variation de l'altitude du sol/sol a également été entièrement implémenté. Cela empêche la pression moyenne de base de changer plus vite que 2.5 mètres par seconde et aide à éviter que les événements de vide ou les événements de pression ne corrompent la pression du sol quand vous mettez un cône de nez ou l'enlevez.

Communication USB

Le Nano peut maintenant être interrogé via certains navigateurs web sur les PC et ordinateurs portables (navigateurs Google Chrome, Microsoft Edge et Opera). 
Cela permet aux utilisateurs de cliquer sur connecter et d'utiliser le configurateur de paramètres Nano sans avoir besoin d'éditer le fichier texte sur l'appareil. Vous pouvez également télécharger les vols en un clic plutôt que de devoir localiser le fichier physique sur le lecteur USB du Nano.

Exemple de la page de téléchargement du chargeur direct du log altimètre via USB.


Capture d'écran de la page Configurer les paramètres via USB, vous pouvez y accéder ici (via la page outils)

Bug de réveil

Cela a affecté le comportement post-vol quand vous avez sélectionné d'entrer en veille profonde après 4 ou 10 minutes après l'atterrissage.
Le minuteur de sommeil du cycle d'échantillonnage restait défini quand la veille profonde était demandée. Le résultat était qu'il se réveillait directement de la veille profonde après quelques millisecondes.
Cela le faisait paraître comme si l'appareil n'allait jamais entrer en sommeil comme demandé.

Réparation de l'altitude via comparaison d'accélération.

À l'allumage du moteur, le capteur de pression a un travail difficile : le panache lave la zone de lancement et le baromètre enregistre un changement de pression atmosphérique qui ne s'est pas produit, ce qui apparaît comme une altitude. Sur certains vols, cela apparaît comme un pic ou un creux autour du décollage, parfois un gros, sur un vol d'essai presque vingt mètres d'altitude qui n'ont jamais été volés. L'accéléromètre ne le voit pas, parce que rien ne s'est réellement déplacé de cette façon, et ce désaccord est tout le principe de la réparation : au début du vol, l'accéléromètre prouve que le panache ne peut pas tromper.

La méthode est délibérément conservatrice. Tandis que l'accéléromètre certifie que la fusée est toujours sur le sol, toute excursion d'altitude est par définition une erreur de pression et la trace maintient le niveau du sol, bien que la dérive normale du sol soit laissée exactement telle que mesurée. Une fois que le mouvement réel commence, l'altimètre intègre l'accéléromètre pour savoir à peu près où la fusée doit être, et utilise cette trajectoire comme un détecteur de mensonge plutôt que comme un stylo : la pression n'est jugée fausse que quand elle s'écarte de la trajectoire attendue plus loin que la moitié de la montée elle-même, un seuil qui s'adapte avec le vol afin que les données authentiques ne puissent jamais le déclencher. Une portion condamnée est alors reconstruite en utilisant la forme de l'accéléromètre pour la courbe, mais ancrée aux deux extrémités à de vrais échantillons de pression, afin que la réparation puisse seulement combler les espaces entre les données mesurées, jamais inventer une ligne de sa propre. Le mécanisme entier s'arrête peu après le burnout, bien avant l'apogée, où le baromètre reprend seul le contrôle, et chaque log réparé garde sa colonne d'altitude brute afin que la mesure originale soit toujours là pour la comparer. En validation sur seize vols enregistrés, seul le vol corrompu par le panache a été modifié ; chaque vol propre est passé inchangé. 

Exemple de la réparation de la corruption de pression précoce sur un log de vol exemple.

Signatures de log dual

Les logs de vol Nano sont signés cryptographiquement sur l'altimètre au moment où ils sont sauvegardés. La vérification sur Altimeter Cloud prouve qu'un log est authentique et intact : changez une seule valeur et il échoue. La clé de signature ne quitte jamais votre appareil, c'est tout l'intérêt, nos serveurs peuvent vérifier un log mais ne peuvent jamais créer la signature pour un, donc une signature valide signifie une seule chose : ces données provenaient de cet altimètre, exactement tel qu'enregistré.

Avec les deux formats CSV et ACLZ maintenant supportés, cette garantie avait une lacune. Votre appareil sauvegarde un format, et quand le site web le convertissait à l'autre pour télécharger, la conversion était honnête mais non signée, parce que le site web ne peut rien signer. À partir du firmware 1.60, l'altimètre ferme lui-même la lacune : à la sauvegarde, il calcule et signe les deux représentations du vol, stocke le format que vous avez configuré, et enregistre les deux signatures à côté de lui. Quand Altimeter Cloud produit le format alternatif, il attache la signature que votre altimètre a déjà faite pour exactement ces données. Si chaque valeur correspond, et elle le fera à moins que quelque chose n'ait été altéré, les deux formats se vérifient. La même protection, les deux téléchargements, signés par rien d'autre que votre altimètre.