Points forts {#highlights}
Les modifications de configuration effectuées au niveau de l'appareil s'appliquent désormais à toutes les sessions client qui utilisent cet appareil, et nonseulement celle qui a écrit le message. Un deuxième lecteur se met à jour via son propre mis à jour lors de la session-Événement, lieu
Concernant le pollen : exactement un événement par séance de collecte, et jamais deux pour la personne qui consigne les données.
La position physique d'un appareil peut désormais être signalée à un client, au lieu que le service doive toujoursMontage indique qui a configuré la session. L'étiquette qui précise laquelle des deux informations vous consultez actuellement,
Cela s'applique désormais, de par la conception même du système, à toutes les formes de publication.
Si un périphérique gère sa propre référence de montage, le service s'aligne sur celle-ci. Jusqu'à présent, le service fournissait une valeur qui, lors de laLa mise sous tension de l'appareil a été enregistrée et n'a jamais été vérifiée à nouveau. Il peut désormais utiliser cette référence, sur demande, selon son propre rythme de rendu
mettre à jour les clients — avec une limitation du débit côté serveur, afin qu'un client rapide ne puisse pas saturer la connexion de l'appareil — et
Signalez cette modification dès que le montage aura effectivement eu lieu.
Améliorations internes {#internal-improvements}
Correction automatique expérimentale de la dérive de lacet de la poignée. Un nouveau module de service complète la boucle de régulation pour laDérive inertielle en lacet du Wireless VerseGrip : il compense la dérive en lacet absolue de la poignée en fonction du mouvement de l'Inverse3 , ou
Minverse ab, auquel il est rattaché. Dès qu'une série de contrôles qualité est validée, il enregistre une seule correction
Retour au micrologiciel de la poignée. Le module est désactivé à la livraison; il ne fonctionne que lorsque la fonction expérimentale est activée.
L'option « Opt-in » est accessible et dispose d'un interrupteur à temporisation qui désactive immédiatement toute poignée active dès qu'elle
est répercuté — ce n'est pas facultatif pour une fonction qui écrit dans le micrologiciel de l'appareil.
Une opération d'écriture de configuration qui concerne tous les appareils simultanément est désormais du type « tout ou rien ». L'ensemble de la sélection est— Fonctionnalités du micrologiciel et état de préparation des appareils — sont validées avant toute modification d'un appareil. Cela permet de gérer un parc composé d'appareils hétérogènes
Les versions de micrologiciel ne doivent plus rester à mi-chemin simplement parce que le deuxième appareil signale une erreur.
Les confirmations du micrologiciel Griff sont désormais suivies pour chaque requête. L'existence d'un seul emplacement commun pour les résultats a conduit à ce que,que deux demandeurs agissant simultanément pouvaient passer à côté de la réponse de l'autre, et qu'une valeur ambiguë pouvait figurer à la fois
tant pour « refusé » que pour « rien pour l'instant » — ce qui pouvait transformer un refus en une avalanche de demandes répétées. Chaque demande
comporte désormais son propre jeton ; une requête qui n'est jamais parvenue à la ligne n'est pas enregistrée, et une réponse perdue
est résolu comme ayant échoué, au lieu de rester bloqué. Le cycle de vérification qui permet cela ne coûte rien, tant qu’il n’y a pas de
La demande est en cours de traitement.
Le calibrage lors de la connexion à la station d'accueil Inkwell n'est pas affecté par les nouveaux tests de fonctionnement du firmware de la poignée. LeLa connexion d'un stylet déclenche un recalibrage complet de la position, qui est effectué pour chaque stylet livré, indépendamment de
que la version du micrologiciel soit correcte. Ce chemin est expressément exclu de la limite inférieure de fonctionnement définie pour les valeurs calculées
Les corrections de cap ont été mises en place, et l'exception est formulée explicitement au point d'appel plutôt que d'en être une conséquence.
Corrections de bogues {#fixes}
La réinitialisation de la compensation de la gravité rétablit désormais la valeur standard réelle, au lieu de surcompenser.Malgré son nom, ce domaine est facteur_d'échelle dans config/compensation_de_la_gravité Pas de multiplicateur : c'est la
Masse utile au niveau de l'effecteur terminal, exprimée en kilogrammes, que l'appareil compense en plus de son propre poids. La réinitialisation
a pris ce nom au pied de la lettre et a mis en avant le facteur « neutre » 1 Encore elle — une charge utile fantôme d'un kilogramme. L'appareil
a ensuite poussé la poignée vers le haut, ce que ne fait pas un appareil qui vient d'être connecté. La réinitialisation fournit désormais le véritable
Revenir à la valeur par défaut : compensation activée, facteur_d'échelle bei 0, c'est-à-dire que l'appareil supporte son propre poids et ne prend pas
Charge utile. Si votre application utilisait la réinitialisation pour augmenter l'intensité de la compensation, réglez
mais en indiquant explicitement la valeur souhaitée.
La réinitialisation du retour à la position initiale permet désormais de la réactiver. La réinitialisation de config/retour_à_l'accueilavait désactivé le retour à la position initiale, tout en indiquant à l'appelant qu'il était activé. Une réinitialisation effectue désormais
rétablit effectivement la valeur par défaut (activée), et la valeur que votre application lit ensuite est celle qui,
car c'est bien lui qui utilise l'appareil.
Une opération d'écriture liée au montage ou à l'alignement au niveau de l'appareil évite que d'autres clients ne se retrouvent avec des valeurs obsolètes.Avant la version 3.5.6, une opération d'écriture était enregistrée directement sur l'appareil lui-même — c'est-à-dire partagée par toutes les sessions utilisant cet appareil
enregistré —, uniquement la configuration du client émetteur, et les routes à l'échelle de l'appareil n'ont mis à jour personne. Chacun
Un autre client sur le même appareil continuait d'afficher l'ancienne valeur jusqu'à ce qu'il effectue une requête. Chaque session active est désormais notifiée.
Une tentative répétée d'amarrage à la station d'accueil Inkwell ne renonce pas après un seul refus. L'état d'une précédenteLes ancrages ont été conservés d'une opération d'ancrage à l'autre, de sorte que le deuxième ancrage a considéré son premier rejet comme la fin de son
traité dans la fenêtre de répétition. La fenêtre de répétition est désormais réinitialisée à chaque tentative d'ancrage.
Problème de concurrence sur les données corrigé au niveau du tick matériel du Wireless VerseGrip. L'identifiant de l'appareil pouvait être réattribué par le thread de connexion,alors qu'un chemin de préparation le lisait sous un autre verrou. L'identifiant est désormais lu une fois sous le verrou correct en tant que
Un instantané est enregistré, et chacun des chemins suivants — y compris les rejets — utilise cette copie.
Correction d'un problème de désynchronisation dans la préparation des messages sur quatre émetteurs du Wireless VerseGrip. Quatre chemins de transmission sortantsont assemblé leur charge utile et leur somme de contrôle, puis ont demandé l'envoi sans lever le verrou d'écriture, de sorte que deux émetteurs
pouvaient s'écrire les uns dans les autres dans la mémoire tampon commune.
Modifications susceptibles d'entraîner des incompatibilités {#potential-breaking-changes}
Aucune modification n'a été apportée à l'API, au format Wire ou aux paramètres. La sortie par défaut est identique, octet par octet, à celle de la version 3.5.5 ; aucune route n'a étésupprimés ou dont le chemin d'accès a été modifié ; l'API C publique ne présente pas de différence, et aucune clé de configuration n'a été renommée,
supprimées ou dotées d'une nouvelle valeur par défaut. Les applications qui utilisent les interfaces de prévisualisation ou expérimentales du SDK
Les fonctions à activer nécessitent toutefois des opérations de migration au cours de ce cycle, notamment une modification du niveau de commutation et la suppression d'un
Ensemble de jetons ; chaque étape est documentée dans le journal des modifications techniques correspondant.
La réinitialisation de la compensation de la gravité donne une valeur différente de celle indiquée au point 3.5.5. Aucun champ, aucun itinéraire et aucunLa structure des réponses a changé, mais une application qui comptait sur la réinitialisation facteur_d'échelle auf 1
indique que la valeur par défaut est désormais rétablie 0 — la compensation elle-même reste activée dans les deux cas. Réglez le
Il faut l'indiquer explicitement, au lieu de se fier à la réinitialisation ; voir la correction ci-dessus.
Le réinitialisation du retour à la position d'origine la laisse désormais activée, et non désactivée. Pas de champ, pas d'itinéraire etAucune structure de réponse n'a changé, mais une application qui comptait sur le fait que la réinitialisation entraînait le retour à la
Si la position par défaut était désactivée, elle est désormais activée. Après une réinitialisation, désactivez-la explicitement si vous souhaitez que
nécessitent ; voir la correction ci-dessus.
Les clients reçoivent des événements de configuration supplémentaires. Une application qui partait du principe qu'un mis à jour lors de la session- Événement uniquement à cause delorsqu'un client modifie un périphérique qu'ils partagent tous les deux, il en reçoit désormais également une,
suivie d'une refonte complète de la configuration. C'est là la conséquence escomptée du « fan-out » décrit ci-dessus ;
Un client qui se reconnecte simplement lors de l'événement ne nécessite aucune modification.
