www.planeur.net | www.netcoupe.net | www.volavoile.net
Jump to content

Robert Ehrlich

Membres
  • Posts

    2139
  • Joined

  • Last visited

Everything posted by Robert Ehrlich

  1. D'après son récit, même s'il n'a pas ressenti de stress au début, l'apparition des symptômes l'a déclenché et ça s'est auto-amplifié.
  2. Comme quoi les dames sont meilleures en mécanique des fluides que les messieurs.Independamment de ces remarques, l'effet Coanda n'a rien à voir avec la portance d'une aile.Fort bien expliqué ici
  3. Et pourquoi pas simplement boucher la fuite à l'epoxy ?
  4. Vieux serpent de mer qui ressort, voir http://www.volavoile.net/index.php?showtopic=7745&do=findComment&comment=64043 Tout le mode a un peu raison et un peu tort.
  5. Je me souviens de la première de ces photos qui était parue je crois dans le Nouvel Observateur, un article disant qu'il abandonnait plus ou moins la politique et se consacrait davantage au planeur. Ce qui fait que je m'en souviens : elle est à l'envers, la fenêtre coulissante et la poignée d'ouverture du parachute sont sur sa droite.
  6. Les deux fichiers devraient avoir le même nom à l'exception du dernier caractère avant ".IGC" qui doit être un chiffre (1 et 2 si c'est le seul vol de la journée). On ouvre chacun avec WordPad, chacun dans une fenêtre différente (clic droit, ouvrir avec..). Pour le premier on va à la fin et on supprime la ligne commençant par la lettre G. Pour le deuxième on sélectionne tout ce qui va de la première ligne à la première commençant par la lettre B exclue, on supprime cette sélection puis on sélectionne tout (Ctrl-A), on copie (Ctrl-C), on va dans l'autre fenêtre à la fin du texte (on devrait y être resté) et on colle (Ctrl-V). On sauve le résultat sous une autre nom (menu fichier, enregistrer sous ..). On ferme cette fenêtre. On ferme la fenêtre de l'autre fichier sans sauver les modifications. On vérifie grâce à un visualiseur de fichiers IGC (SeeYou ou autre) que ça fait bien un vol correspondant à ce qui a été effectué. Dans la logique des noms de fichiers IGC, le fichier résultat (celui qu'on a sauvé par "enregistrer sous ...) devrait porter le même nom que le premier, mais il vaut mieux garder les noms, donc les fichiers, d'origine pour pouvoir recommencer en cas de fausse manip. Par ailleurs on reste dans cette logique en choisissant un nom qui ne diffère que par le chiffre avant ".IGC", en mettant 3 par exemple si les deux premiers étaient 1 et 2.
  7. On peut même dire "qui est président DU club d'Equateur", puisqu'il n'y en a qu'un.
  8. Lu dans ce manuel : ELINGUE : Sous ensemble du câble d’environ 9 mètres qui relie le pied du parachute et l’avançon. Qu'appelle-t-on "pied" du parachute ? Quand il est déployé et vertical, il me semblerait logique d'appeler "pied" l'endroit ou les suspentes se rejoignent pour être connectées au (reste du) câble, et "sommet" l'endroit opposé où vient se fixer cette élingue.
  9. Ce n'est pas une bonne idée d'avoir un des 3 points de référence de la polaire dans le domaine des grands angles. Avec 3 points les calculateurs utilisent en général une approximation parabolique et c'est dans le domaine des grands angles que cette approximation marche le mions bien. La polaire réelle dans ce domaine se termine du coté des basses vitesses avec une tangente verticale et aucune approximation parabolique ne peut reproduire ça. Par ailleurs cette approximation sert surtout à calculer une vitesse de transition optimale (fonction McCready) et dans ce cas on est toujours dans le domaine des vitesses supérieures à celle de finesse max, donc il vaut mieux que les 3 points y soient. Un choix assez classique consiste à prendre le point de finesse max, un point dans l'arc vert et un point dans l'arc jaune. La piètre approximation obtenue avec le courbe bleue dans le graphique publié plus haut illustre bien le défaut du choix d'un point en dessous de la vitesse de finesse max.
  10. Si tu veux éviter ça à l'avenir, insère ces choses plutôt comme "code" que comme "citation" (le bouton à coté à gauche dans le menu).
  11. Ceci semble répondre a ce défaut : Après réflexion, il me semble que ça ne change rien à la question. Peu importe que le détail de l'algorithme de calcul du GRecord soit caché, si cet algorithme est disponible via ce DLL, il peut être utilisé pour fabriquer un GRecord pour n'importe quel fichier IGC.
  12. La solution pour éviter ça existe bien en continuant a avoir un système anti collision efficace : les options de "no trak" ou de "stealth" dans la configuration du Flarm permettent de ne pas être reporté sur le port série d'un autre Flarm (en gros la même chose que le système OGN).Ce n'est pas une solution dans l'hypothèse que j'évoquais. De toute façon un Flarm émet ses données. Un récepteur "coopératif" comme un autre Flarm peut refuser de communiquer ce qu'il reçoit pour respecter les "no trak" ou "stealth", mais un récepteur fait pour détecter des infractions n' aucune raison de le faire, au contraire il peut considérer que ces indications présument une probabilité d'infraction.
  13. Ce n'est pas une question de vitesse par rapport à l'air ou par rapport au sol. Les lois de la physique sont les mêmes dans tous les référentiels galiléens. Le sol en est un, approximativement. L'air aussi dans la mesure ou il se déplace à vitesse constante en force et direction. On peut donc raisonner dans ce cas dans le référentiel air et c'est dans ce référentiel que la composante horizontale de la résultante aérodynamique (force déviatrice) est constamment perpendiculaire à la vitesse et donc que la trajectoire est un cercle. Mais un référentiel qui tourne avec une masse d'air en rotation n'est plus un référentiel galiléen. Si la rotation est le seul mouvement de la masse d'air, le référentiel sol convient et on obtient bien un rayon plus faible si on tourne en sens opposé à la rotation de l'air puisque la vitesse est plus faible. Si en plus de son mouvement de rotation la masse d'air a un mouvement global de translation (par rapport au sol), il convient de prendre un référentiel (galiléen) animé de ce même mouvement de translation (c'est celui dans lequel la force déviatrice est encore perpendiculaire à la vitesse) et dans ce référentiel la vitesse du planeur qui tourne à l'opposé de la rotation de l'air est là encore plus faible et donc le rayon de virage aussi. On peut évidemment aussi raisonner dans le référentiel non galiléen qui tourne avec la masse d'air, mais alors les lois de la physique ne sont plus les mêmes, il faut rajouter force centrifuge et force de Coriolis, ça devient plus compliqué mais le résultat est le même : rayon de virage plus faible si on tourne à l'opposé de la rotation de l'air.
  14. Si les gardes veulent vraiment nous faire chier, ils n'ont pas besoin d'OGN ou toute organisation similaire, ils peuvent très bien installer leurs propres récepteurs Flarm et y coupler un logiciel de détection d'infraction, de la même façon que certains clubs, dont le mien, ont mis en place un système de planche automatique. La seule solution pour échapper à un tel repérage est de couper le Flarm. Ce n'est pas la mienne, qui consiste à ne pas voler dans ces parcs, même au dessus de 1000 m sol, vu que je ne sais pas garantir de pouvoir respecte cette limite.
  15. La manip n'est pas bien compliquée. Il faut ouvrir le fichier IGC avec l'éditeur de texte le plus stupide possible, tout ce qu'on lui demande est d'afficher des lignes et/ou d'en supprimer (surtout pas Word qui va rajouter des indications de polices, mise en page et autres auxquels aucun lecteur de fichier IGC ne comprend rien). Sous Windows, Wordpad ou Bloc-Notes conviennent. Sous Unix, j'ai un faible pour "ed". Le fichier commence par un en-tête du style : AXFLSO1 HFDTE210516 HFFXA500 HFPLTPilotincharge:CVVFR HFCM2Crew2: HFGTYGliderType:DUO-DISCUS HFGIDGliderID:F-CIDJ HFDTM100GPSDatum:WGS84 HFRFWFirmwareVersion:Flarm06.05 HFRHWHardwareVersion:Flarm06 HFFTYFRType:Flarm HFGPSu-blox:TIM-LP,16,8191 HFPRSPressAltSensor:Intersema MS5534B,8191 HFCCLCompetitionClass: HFCIDCompetitionID:SM I023638FXA3940SIU B1122404403778N00559446EA004240051000212 B1122484403778N00559446EA004240051000212 B1122564403779N00559446EA004250051100212 LFLA11225602rio;AfYa?I?j=kyjZk]j%khsZs]r L'en-tête finit par la ligne qui commence par "I" (qui en fait partie). Pour un fichier "comme prévu", il peut encore y avoir des lignes commençant par "C", ou autres. On est certain que l'en-tête est terminé à la première ligne commençant par "B". Les lignes qui commencent par "B" sont des points de la trajectoire, les autres sont sans importance (les "LFLA" sont + ou - spécifiques Flarm). Les 12 premiers chiffres après le "B" sont l'heure UTC du point en heure, minutes, secondes (HHMMSS), suivent la latitude (terminée par "N" à Saint Auban) et la longitude (terminée par "E"), puis la ou les altitudes (pression et/ou GPS). L'extrait de mon fichier est un vol à Saint Auban, on voit qu'avant le décollage la position reste fixe ainsi que les deux altitudes (424/425 et 510/511 m, ce qui colle + ou - bien avec les 460 m officiels du terrain). Il faut repérer les lignes correspondant à l'arrêt au sol, qui vont ressembler à celles-ci (position et altitude fixes à peu de chose près) et supprimer tout ce qu'il y a après sauf la dernière ligne commençant par "G" pour ne garder que le premier vol, supprimer tout ce qu'il y a après l'en-tête et avant l'arrêt au sol pour ne garder que le deuxième vol. Dans l'un ou l'autre cas il vaut mieux sauver le résultat sous un nom différent (enregistrer sous ...). Si on veut respecter les règles de nommage des fichiers IGC, le nom doit être quelque chose comme "65R????n.IGC", le fichier d'origine devrait porter un nom de ce style. Le début ("65R") correspond à la date du 27 Mai, les 4 "?" correspondent au type et numéro de série du logger (les 3 derniers devraient être identiques aux trois derniers caractères de la première ligne du fichier IGC (AXFL???), il faut donc conserver tout ça, on ne peut jouer que sur le dernier caractère (n) avant le ".IGC" qui est un numéro d'ordre, il faut donc y mettre un chiffre quelconque (un seul) différent de l'original.
  16. Faire un fichier IGC correct à partir d'un ou plusieurs fichiers IGC ne pose pas de problème en soi, si ce n'est pour la signature numérique du résultat, qui en principe est impossible à produire correctement, c'est bien à ça que sert cette signature. Toute la question est de savoir si cette signature est exigée par la NetCoupe. Je me souviens d'avoir eu le problème lors d'un concours où mon fichier Flarm a été coupé en deux suite à une coupure d'alimentation électrique. J'avais donc deux fichiers corrects et correctement signés mais le logiciel de scoring ne savait pas faire avec deux fichiers. Les organisateurs ont été d'accord pour accepter le fichier unique que j'ai fait en raccordant le premier sans la signature avec le second sans l'en-tête, avec sa signature donc incorrecte pour l'ensemble. Le logiciel de scoring ne vérifiait pas la signature. Ceci dit l'authenticité fournie par cette signature est quand même un peu faible dans la mesure ou des fichiers IGC créés par XCSoar sont acceptés. Comme les sources sont publiques, n'importe qui peut y recopier l'algorithme de calcul de cette signature et ainsi fabriquer une signature XCSoar correcte pour n'importe quel fichier IGC.
  17. Les grandes viles françaises non plus. Les villes, peut-être bien que oui! N'exagérons rien, le pluriel ne me semble pas de mise, jusqu'ici, sauf erreur de ma part, en France , il n'y en a qu'une. Et encore, pour ce qui est de Paris proprement dit ce n'est pas de la classe A mais une zone P. Vous me direz, pour nous c'est du pareil au même.
  18. Si ça n'existe pas en RJ12, ni en femelle RJ12, la solution que je proposais de long câble femelle-femelle monotoron avec raccord court mâle-mâle à chaque bout marche toujours, il suffit que les mâles-males soient pourvus d'une prise RJ12 d'un côté et RJ45 de l'autre. Pour ne pas s'emmerder à repérer les couleurs de fils de chaque coté, autant prendre du câble plat, même si la qualité n'est pas top, sur une très faible longueur ça n'a pas d'importance.
  19. Mais ce qu'on demande à un câble réseau n'est pas ce qu'on demande à celui qui fait la liaison entre un FLARM et un afficheur distant. Le câble réseau doit passer des fréquences élevées avec de faibles courants. Pour un FLARM, à 4800 b/s, on est loin du gigabit/s des bons câbles réseau, par contre, si l'afficheur n'a pas sa propre alimentation, il faut passer de la puissance. Aux fréquences élevées, à cause de l'effet de peau, c'est la surface extérieure du conducteur qui importe, le multibrin est favorable, par contre aux fréquences basses c'est le contraire puisque c'est la section qui compte. Pour ce qui est du câble plat, bien que théoriquement il soit inadapté pour du réseau, il se trouve que chez moi il y en a environ 10 m qui passe parfaitement le 10 Mb/s, ce qui me sufft bien. Je ne sais pas s'il est chinois, en tout cas le doublement de son prix ne me gênerait pas : il ne m'a rien coûté, toute mon installation est de la récup.
  20. Pourtant c'est ce qui est utilisé pour les câbles fixes derrière les prises murales. Il est vrai qu'ils sont sertis dans des prises femelles et non des prises mâles comme celles des câbles qui raccordent FLARM et display déporté. Si seules ces prises son adaptées aux conducteurs monobrin, une solution au problème de Bob pourrait être d'avoir deux câbles mâle/mâle très courts aussi bien côté FLARM que côté display, reliés par un câble femelle/femelle de la bonne longueur en monobrin.
  21. Ces variations impliquent des écarts entre l'altitude réelle et celle qu'indique un altimètre calibré et calé (QNH=1013,25)pour l'atmosphère standard, ce qui n'est pas pertinent pour la discussion qui porte sur la correspondance entre l'altitude indiquée par un altimètre gradué en mètres et calé au QNH du jour et celle indiquée par un altimètre gradué en pieds et calé à 1013,25, les deux étant étalonnés selon l'atmosphère standard.
  22. Je ne vois pas bien en quoi ça pourrait ne pas être compatible avec les prises RJ12, si ce n'est qu'il y a 2 fils de trop, qu'il suffit de séparer des autres et couper avant de sertir les 6 autres dans la fiche. Ca pourrait au contraire résoudre le problème, dans la mesure où un mono-conducteur,pour un même diamètre extérieur, a une section utile plus grande, donc une résistance plus faible, et le problème semble bien être un problème de résistance.
  23. Il y a un doute sur la valeur en mètres de l'hectopascal. Le code affiché plus haut utilise 8.5344, qui résulte de la conversion en mètres de la valeur en pieds 28 ft. Si on utilise la valeur la valeur plus précise 27.3052967825 citée entre parenthèses, on obtient 8.32. C'est aussi ce que donne l'équation de l'équilibre hydrostatique deltap = -g*rho*deltaz, avec g=9.81 m/s2 et rho=1.225 kg/m3.
  24. Après relecture attentive de la doc FLARM, je fais quelques constatations : Même sur la prise 6 points, la masse (GND, contact 8) est déjà dupliquée en 4 (selon la numérotation RJ45, que FLARM adopte également pour la RJ12 en faisant commencer la numérotation à 2). Donc duplication sans doute inutile pour elle. Pas de définition claire des tensions fournies ni utilisées coté RJ12. Il y a 12 V sur le contact d'extrémité (2 en numérotation FLARM) mais on ne dit pas s'il est fourni ou reçu, 3V sur le contact 3 et là il est précis qu'il est fourni, mais il 'est pas précisé si c'est lui qui alimente le display. Par contre c'est bien dit dans la doc du PowerFLARM. On peut conjecturer que c'est le cas pour tous et dans ce cas c'est le fil correspondant qu'il faudrait dupliquer ou remplacer par un plus gros.
  25. Il ne peut pas y avoir de perte de courant, sauf défaut d'isolation. Par contre il peut très bien y avoir une perte de tension, je dirais même qu'il y en a toujours une, c'est la loi d'Ohm, elle ne peut-être considérée comme négligeable que si la résistance du câble l'est elle-même, ou le courant qui le parcourt. Ce genre de câble est conçu pour transmettre des signaux en tension avec des courants relativement faibles, or sur un display déporté il faut aussi acheminer de la puissance pour allumer les LED et alimenter le microprocesseur qui est dedans. On lit dans le manuel FLARM que le brochage du petit connecteur (6 contacts RJ12) est le même que celui du grand (8 contacts RJ45) dont on aurait enlevé les contacts extrêmes (1 et 8). Or ces contacts sur le grand connecteur dupliquent les fonctions de leurs voisins (2 et 7) qui acheminent tension d'alimentation et masse. Il paraît clair que cette duplication est là pour compenser la résistance trop élevée d'un câble non prévu pour acheminer de la puissance. Il n'est pas étonnant que sans cette duplication on atteigne assez vite une longueur pour laquelle la résistance de ces deux fils devient trop élevée pour transmettre le courant nécessaire sans perte de tension rédhibitoire. Une solution serait probablement, si mon explication est la bonne, de refaire une duplication par deux fils externes connectés au plus près des prises aux fils extrêmes, ce qui doit demander un bricolage délicat mais faisable pour atteindre ces deux fils extrêmes à travers les isolants. Les raisons pour lesquelles on ne peut pas connecter deux displays sont multiples, d'abord le même problème de puissance à transmettre, que le FLARM n'est peut-être pas capable de fournir, mais surtout la transmission série bidirectionnelle. Si le signal émis par le FARM peut fort bien être transmis à deux displays, par contre si on tente de transmettre les signaux émis par les deux displays vers un seul contact du FLARM, cela revient à connecter ces deux sorties ensemble et si elles sont en état contradictoire, cela revient à un court circuit qui peut cramer le composant produisant ce signal dans un display ou les deux. La norme RS232 prévoit des résistances internes à ces composants qui excluent la chose, mais qui la respecte ? FLARM n'a jamais dit d'ailleurs que ses canaux série étaient conformes à cette norme et met bien en garde l'utilisateur sur le risque de détérioration en cas de non respect de cette prescription.
×
×
  • Create New...