TI ez430-chrono

#101

Tchô,

TiBo, pacoman - désolé les gars, je me suis un peu laissé emporter dans un jargon qui n’a rien de parapentesque, c’est vrai qu’on n’est pas sur un forum de développeurs ici :roll:

Donc, quoi faire des fichiers ?

Le “binaire pour Chronos”, tu le charges sur ta montre ezChronos, soit par le Control Center à travers la mise à jour rfbsl, soit en la branchant sur ton pc directement (voir ez430-Chronos User Guide, la section qui parle du chargement des applications). Si t’as pas de montre ezChronos en 868MHz, ca ne te sert à rien. Si t’as la montre mais à une autre fréquence, je peux te recréér un binaire fait pour.

Le fichier patch, c’est pour mettre à jour le code source de base pour pouvoir le modifier et le recompiler, si tu n’es pas développeur ca ne te sert à rien…

(attention je vais reparler chinois en-dessous)

marc, si tu veux mettre le patch dans ta branche, c’est avec plaisir, je suis pas encore up to speed avec git (et git-format-patch ne me donne rien pour l’instant, soit j’ai pas la bonne syntaxe, soit c’est parce que j’ai déjà fait un git add des modifs sur mon clone du master). Mais si t’es trop divergent par rapport à poelzi, c’est peut-être pas évident, dans ce cas je peux me pencher dessus de mon coté dès que j’ai un moment.

Sinon, s’il y a des idées de choses à ajouter, farfelues ou pas, je suis tout ouïe :dent: ! J’ai quelques trucs en tête, mais toutes les idées sont les bienvenues !

:rando:
Marc

ps: Vu le volume sonore très faible du buzzer de la montre, je ne suis pas convaincu que l’usage en altivario sonore soit très convaincant (je préfère de loin mon solario). Mais comme altimètre ok, et il y a un paquet d’autres applications auxquelles on peut penser, le capteur de pression est assez précis quand même… et il y a d’autres capteurs.

#102

je tente d’intégrer dans la journée.
Sinon, dans l’aide de ‘format-patch’ tu as des exemples. Il faut lui dire quels commits tu veux. Le plus simple est souvent d’envoyer les ‘n’ dernier commits:
$ git format-patch -n
Ca va faire n fichiers que tu peux envoyer. Le gars qui reçoit ça peut appliquer simplement avec la commande ‘am’ (ça permet d’avoir les messages de commits, les auteurs des commits, etc).

#103

OK moi aussi j’ai joué un peu avec “dans le temps”.
Quelques remarques en vrac :

  • Comme tu l’a intuiter, utiliser une petite formule utilisant : la différence de pression, et la masse volumique de l’air doit donner de meilleurs resultat que la différence d’altitude (La masse volumique de l’air tu peux la trouver avec les pression et température courrante).
  • J’avais monté la fréquence d’échantillonage ce qui obligeait à lisser un peu plus, et modifier la durée du tick “global”, mais qui donnait une réactivité bien meilleur (au détriment de la consomation)
  • La correction des températures matérielle, c’est pour la déviation interne de la puce, il faut quand même corrigé/caler pour ton calcul d’altitude.
  • Si tu essaie d’utiliser les accelerometres il faut vraiment les calibrer comme il faut et corriger. Car c’est tous tordu. Normalement il y a un callage fait à l’usine, mais là je soupçone qu’il y ai utilisation de matériel non calibré, ou n’ayant pas passé les tests de qualité.
#104

marc - comme tu veux. J’ai fini par trouver comment faire marcher format-patch (fallait que je me crée une branche perso plutôt que bosser sur le master), donc si tu veux les changements sous ce format, no souci. Sinon, le dernier patch est ici, j’ai fait une petite modif pour moyenner la pression si l’alti la met à jour plus qu’une fois par seconde (au cas où on changerait la fréquence d’échantillonnage), et réduit la taille des data un peu pour pouvoir compiler sans FIXEDPOINT.

Le binaire ezChronos 868 est ici, à priori ça devrait pas changer coté fonctionnalité du dernier, à part qu’il est un peu plus gros. Mais ca rentre quand même :pouce:

touz, effectivement la compensation en interne ne joue pas sur la masse volumique, bien vu. Si on veut être encore plus précis, faudrait aussi l’humidité de l’air, mais bon, pour savoir si on monte à 0.1 ou 0.094m/s, ca me semble un peu overkill en pratique, d’autant que le capteur à une précision de 1.5Pa, donc +/- 0.15m/s … :stuck_out_tongue: .

Les accéléromètres, je m’en tiens à distance pour le moment :grat:

:rando:
Marc

#105

:pouce:

#106

hello,
suis super content de voir que vous avez repris le flambeau, car moi j’ai pas trop le temps de m’y consacrer pour l’instant… à mon grand regret… :frowning:
je regarderais ça un de ces jours… :wink:

#107

:trinq: fertito !

Y a du nouveau :dent: !

J’ai fait un son correct pour le vario (modulé en fréquence aussi), et différents réglages sonores:

  • pas de son (oui bon ça ça marchait déjà :roll: )
  • son à la montée, commencant à biper en zérotant.
  • son à la montée, commençant à biper à 0.1m/s pour ceux qui n’aiment pas le premier :boude:
  • son à la montée et à la descente, rien si ça zérote.

L’icone du beeper est mise à jour en fonction du réglage.

J’ai fini par trouver une façon de moduler les sons qui me semble facile à interpréter, en plus d’être économe en code (c’est à bloc, j’ai du optimiser pour que ça rentre encore, et pourtant ca tient en 896 bytes ! :affraid: ).

A 0.0, un seul bip par seconde, à 1.8kHz
De 0.1 à 0.5m/s, un seul bip dont la fréquence passe de 2.0 … 2.3 … 2.7 … 3.3 … 4.1kHz (environ).
De 0.6 à 1.0, deux bips, même augmentation de fréquence.
De 1.0 à 1.4, trois bips
et ainsi de suite. Bien sur, plus il y a de bips plus ils sont brefs, pour pas dépasser la seconde.
Pareil en négatif, avec des fréquences passant de 1.6 … 1.5 … 1.4 … 1.3 … 1.2kHz.

Ca reste bien audible avec le petit piezo, les fréquences plus basses genre 600Hz sont un poil faibles je trouve.

J’ai plafonné volontairement le vario sonore à 25m/s, pour pas trop stresser le pilote :twisted:

Voilà… comme d’hab, le binaire à charger dans la Chronos 868.

…et pour marc, un tar avec les patchs successifs en git format-patch - c’est vrai que les commentaires du commit c’est pas mal, je vais continuer comme ça et probablement me faire un compte sur github un de ces quatre pour y mettre ma branche, ce sera plus facile à maintenir.

Bon j’arrête là pour l’instant, le vario moyenné suivra un jour… de toute façon pour rajouter des fonctionnalités faudrait que je compile en FIXEDPOINT ou que je vire d’autres modules qui ne servent à rien en vol…

Il nous reste à tester tout ça ! :ppte:

:rando:
Marc

#108

:coucou:

marc, j’ai créé un fork perso (catsup) et intégré mes changements, je fais un pull request sur le master de poelzi pour avoir une base clean pour les changements futurs.

Marc

#109

Merci Zebu !

#110

Bon, là je suis dépassé, tu vas trop vite. Du coup, maintenant que t’as un compte sur github, je vais simplement détruire mon fork, ça sera plus simple.
En tout cas, chapeau pour la surmotiv et la productivité !!
Tu sais que github te permet de mettre en téléchargement des “version” du soft. Là, ça veut dire que tu peux mettre en dl le “binaire” flashable :slight_smile:

karma+

#111

Bon, autant pas mourir ignare …

C’est quoi Github ? (un serveur ?)
C’est quoi un fork ? (un compte ?)
C’est quoi un pull request ? (???)
C’est quoi Poelzi ? (un programmeur ?)
C’est quoi git ? (…)
C’est quoi OpenChronos ? (un language ou un programme ?)

Si vous avec le temps de répondre, n’hésitez pas à me prendre pour un con en expliquant les choses les plus évidentes pour vous …

#112

Bon, je vais essayer de mettre ça dans mon bouzin de poignet!

Et karma+ Zebu pour tout ça!

#113

un site web qui te permet d’utiliser des outils de développement gratuitement. Pour github, ça te permet d’utiliser un outils “git” pour gérer le code source d’un programme quand tu . développe à plusieurs. Ce site te permet de publier ton code et d’interagir plus facilement avec d’autres développeurs (git est un outils libre, dispo gratuitement, et tu n’as besoin de rien d’autre pour t’en servir, mais github te rend la vie plus facile)

Un logiciel, c’est un code source. Si quelqu’un souhaite modifier un logiciel à sa sauce, il va prendre ce code et le modifier. C’est cette action de prendre un truc existant et le modifier qu’on appelle “forker” (en bon français, bien sûr :mrgreen: ça vient de “to fork”, fourchette). Faut voir le lien de parenté pour comprendre le mot “fork” (fourchette): une version est commune aux 2 versions, mais après, chacune vit sa vie, ça fait 2 branches te ta fourchette.
Regarde le schema de wikipedia: http://en.wikipedia.org/wiki/Fork_(software_development)
Tu la vois la fourchette ? :slight_smile:

là c’est plus technique… Quand tu fais un “fork” d’un logiciel existant, c’est pour le modifier. Peut être que plus tard, tu voudrais faire profiter le logiciel d’origine de ta modification. Tu va demander à son auteur de faire un “pull” sur ton “fork” (ta branche, en fait). Faut s’imaginer que l’auteur va ‘prendre’ (tirer vers lui / “to pull”) tes changement et les intégrer dans sa version.

oui, à l’origine d’openchronos

un outils de gestion de version de logiciel (en gros, mais en détail, c’est pas tout à fait vrai)
http://git-scm.com/

Pour la petite histoire, c’est l’auteur de linux (Linus Torvalds) qui a codé ça sur un coin de table quand il a trouvé qu’aucun outils disponible (à l’époque) ne lui convenait. En à peine quelques jours/semaine, il a pondu un truc qui fait maintenant parti des références quand on parle de ce genre d’outils…

le nom d’un logiciel qui va sur la montre de TI dont on parle ici.

j’espère avoir répond de façon claire… Sinon, demande des précisions :slight_smile:

#114

m… j’ai rédigé une réponse sur le fork pour rien … Marc est plus rapide …

#115

:pouce:
Merci, c’est parfait !!! (et c’est un peu plus clair)

De toute manière, plus, ça aurait été trop … là, j’ai largement atteint mon seuil d’incompétence !!!

#116

Bon, test en voiture aujourd’hui, puis en vol dans du tout petit petit, des bons gros thermiques à 0.2 :affraid: … avec la montre par-dessus le blouson, ç’est bien audible, en fait c’est même plutôt sympa d’avoir un son aussi faible, on en vient presque à l’oublier ! Ce qui ne m’a pas empêché de faire des ronds dans le ciel pendant une bonne grosse heure 8)

J’ai quand même trouvé un bug :fume: - l’altimètre d’origine se met en veille au bout d’une heure, ce qui est bien géré dans le vario en affichant “noAlt”, mais en le réenclenchant, on se retrouve avec des pics monstres, selon l’altitude qu’on a gagné ou perdu. C’est sympa pour vérifier les sons, mais ça fausse les statistiques des Vzmin/max.

Et puis une fois posé, quand on a comparé nos vols avec les copains, j’avais pas mon plaf maxi :frowning: ! Va falloir que je rajoute ça…

Bien le plan de mettre en téléchargeable des versions compilées, ça va faciliter la vie de tous ceux qui ne veulent pas recompiler :pouce: je tacherai d’y mettre les prochains binaires.

:rando:

#117

Oui-oui je te l’accorde sans sourciller : pour un vario on c’en cogne des 0.006 m/s.
Mais j’avais en tête d’utiliser ça pour faire des mesure d’altitude. Genre gain par thermique entre le moment ou tu commence à monter et le moment ou tu monte plus.
Dans ce cas (dans le thermique, t’es assez loin de l’atmosphère standard).

Et puis j’suis un peu estète sur les bords 8)

Vu mon état de fainéantise, je trouve comment dire …que c’est une idée absolument génialissime. karma+

#118

Sympa l’idée du gain dans le thermique :pouce:

Je vais voir comment ca marche pour les téléchargements par version sur github, après j’y mettrai les binaires.

Mais d’abord je fixe mes deux bugs: Le bip mal calculé (à vouloir être trop économe en mémoire et essayer de stocker 16 bits dans 8 :roll: ), et le coup du pic de Vz après avoir rallumé le vario. Pour celui-là, le fait que l’altimètre essaye de lisser les changements ne me facilite pas la vie :grrr2:

Puis faudrait aussi que je :dodo: un peu…

:rando:

#119

Merci Marc de nous faire évoluer le bouzin !
J’adore vous lire quand vous parlez votre langue : l’impression étrange de lire un texte étranger écrit avec des mots presque français !

#120

Merci :coucou:

Bon j’ai mis en place le binaire avec les derniers fix eZChronos-868-catsup-v0.1. Par contre j’ai pas vu comment l’associer à un tag, c’est pour ca que tout est dans le nom…

Ca gère les petits changements d’altitude quand on éteint et allume l’alti, mais si on éteint en bord de mer et rallume sur le mont blanc (et même plus bas), ca va fausser les Vz, donc faut les effacer… trop de taf de suite pour fixer ca.

Plus de news + tard, :grrr: