l'orbite basse est-elle circulaire ou élliptique

soussou a écrit:mais SVP est ce qu'il y a des sources de programmes en matlab?

Soussou, l’objectif de ton Master, c’est le calcul du bilan de liaison, ou le logiciel d’orbitographie?
Si je prends le 1er logiciel cité par Steph, il fait des milliers de lignes en Pascal, que tu es obligé de traduire en MatLab si je comprend bien (trouver des sources en Matlab, je doute fort, en général, c’est Pascal, Delphi ou C++)
Donc pourquoi ne pas exploiter les OUTPUT des logiciels existants pour alimenter ton simulateur?
Bon courage

Firnas2 a écrit:
Soussou, l’objectif de ton Master, c’est le calcul du bilan de liaison, ou le logiciel d’orbitographie?
Si je prends le 1er logiciel cité par Steph, il fait des milliers de lignes en Pascal, que tu es obligé de traduire en MatLab si je comprend bien (trouver des sources en Matlab, je doute fort, en général, c’est Pascal, Delphi ou C++)
Donc pourquoi ne pas exploiter les OUTPUT des logiciels existants pour alimenter ton simulateur?
Bon courage

En faite, l'objectif c'est de réaliser un logiciel qui intègre les 2, l'orbitographie et le bilan de liaison; à la suite faire une optmisation de la station au sol.
Est-ce que y a un outil de traduction des lignes de pascal en matlab ou je dois le faire moi même?
Et comment puis-je exploiter les OUTPUT des logiciels existants, j'ai pas compris ce point.

D’abord il faut faire la différence entre exploiter un logiciel existant et écrire un nouveau logiciel.
Pour le 2ème cas, je suppose qu’à partir des réponses déjà données ci-dessus tu as mesuré la tache qui t’attend.
Pour le 1er cas et pour répondre à ta dernière question, si tu possèdes la source du logiciel, que je suppose bien documentée, se basant sur le manuel d’utilisation, tu dois comprendre les paramètres d’entrée et les résultats qu’il fournit. S’il y a des flous, tu dois envoyer des mails à l’auteur (les auteurs). Concernant les algorithmes qu’ils utilisent, en général ils te renvoient à des bibliographies que tu dois bosser si tu veux comprendre. Pour ton cas, il suffit d’ajouter quelques lignes pour demander au logiciel d’écrire les résultats dont tu as besoin dans un fichier (Tu feras bien sûr une autre compilation …). Tu vas demander au Matlab de lire ce fichier et moyennant les autres données, faire les simulations nécessaires.
Nos spécialistes du forum, vont certainement me corriger si je me trompe.
Pour ta recherche bibliographique, inspires toi des cours magistraux et bagages scientifiques, que les universités françaises donnent à leurs étudiants, pour ce genre de Master.
Pour conclure, si tu arrives à bosser pour atteindre les deux objectifs, qu’ils t’ont fixés (ou que tu t’es fixé, j’aime bien le savoir) tu sera pionnière en mécanique spatiale et orbitographie dans nos universités.
A+

soussou a écrit:mais SVP est ce qu'il y a des sources de programmes en matlab?

Je rectifie mon avant dernier post, le NORAD SGP4/SDP4 est disponible en Matlab:

SGP4 Pascal Library Version 2.65
sgp4-plb26a.zip, 102,352 bytes, 2000-Jan-22
This Turbo Pascal source code implements the NORAD SGP4/SDP4 orbital models for use with the standard two-line orbital element sets to determine earth-centered inertial (ECI) coordinates of earth-orbiting objects. This code implements both the near-earth and deep-space portions of the NORAD SGP4 orbital model. This version has routines for calculations of spacecraft subpoint and topocentric circumstances such as azimuth, elevation, range, and range rate or right ascension and declination—and even takes atmospheric refraction into account. NOW calculates visibility conditions, making it perfect for predicting visible passes of Mir or the US space shuttle.

Unit SGP_TIME.PAS (routines Julian_Date_of_Epoch and ThetaG) modified to correctly interpret epoch year in the two-line element sets beyond the Year 2000 (through 2056).

A C++ version of this code, developed by Varol Okan, is available from http://www.movingsatellites.com/e_gps.html.

A C++/C# version of this code, developed by Michael Henry, is available from http://www.zeptomoby.com/satellites/.

A Java version of the SGP4 portion of this code, developed by Pedro J. Fernandez, is available online in PassFinder.zip.

A complete rework of the SGP4 code found in Spacetrack Report Number 3, developed by David A. Vallado, Paul Crawford, Richard Hujsak, and T.S. Kelso, is available online in "Revisiting Spacetrack Report #3. Source code is available in C++, FORTRAN, MATLAB, and Pascal. Highly recommended.

Le Matlab est dans ce lien:
http://celestrak.com/publications/AIAA/2006-6753/
avec un document pdf de 88 pages, qu'il faut éplucher.

A+

Tout dépend de la précision que tu souhaites atteindre dans tes calculs. En pratique, on cherche rarement le pouillème de dB dans un bilan de liaison, car les incertitudes sur les divers paramètres sont du même ordre.
Si tu ne veux pas te lancer dans une usine à gaz je te suggère d'adopter la démarche suivante (purement cinématique):
On se place dans un repère inertiel par rapport aux étoiles centré sur la terre. Selon les gouts, on peut aligner un axe du repère avec l'axe des poles ou choisir un axe z orthogonal au plan orbital terrestre. Il est sans doute plus simple de s'aligner sur l'axe des poles. Le dit repère est alors en translation autour du soleil mais on s'en tape gaillardement dans l'approche suivie.
On décrit la trajectoire du satellite dans ce repère. Peu importe qu'elle soit circulaire ou elliptique. On obtient donc un vecteur OS(t) qui donne la position du satellite dans ce repère inertiel. On considère la station de réception comme liée à un repère tournant de même centre que le précédent. En alignant l'axe des pole avec le repère fixe les équations sont plus simples. Ce repère tournant est animé d'une vitesse constante: 2*Pi/24h...Le vecteur donnant la position de la station dans le repère fixe est donc OR(t)
qui se calcule assez facilement puisqu'il s'agit d'une rotation simple sur un axe.
La distance terre station est donc simplement le module de OR(t)-OS(t) qui va te servir à calculer l'atténuation d'espace dans ton bilan de liaison.
La trace au sol s'obtient en calculant l'intersection du vecteur OS(t) avec une sphère animée du mouvement rotation terrestre.
On peut tenir compte de la précession orbitale en corrigeant la vitesse apparente de la rotation terrestre.
Dans ce genre de jeu, il est souvent utile d'exprimer les grandeurs sous forme vectorielle, par exemple si tu veux calculer un angle sur l'horizon local ou autre et de se doter de fonctions manipulant directement des vecteurs. L'angle de site sur l'horizon est utile pour déterminer les périodes de visibilité du satellite. En général on a du mal à transmettre en deça de 5 ou 10°.
Pour finir, attention à un paramètre souvent oublié dans les bilans: la disponibilité de la liaison qui joue sur le bilan à travers l'atténuation de pluie. Entre 0.99 et 0.999 on peut manger quelques dB assez facilement. Ne pas oublier le taux d'erreur cherché qui te servira à évaluer l'Eb/N° objectif de ton bilan.
Ce n'est certainement pas le schéma de simulation le plus fidèle, mais ça devrait suffire pour dégrossir la question.

Bon courage et Bons Vols.

soussou a écrit:Merci pour vos réponses.
Bon, mon projet c'est de réaliser un simulateur pour visualiser la trajectoire d'un satellite en orbite basse et par la suite étblir un bilan de liaison entre ce satellite et n'importe quel point sur terre, tout en cherchant le meilleur endroit pour placer la station au sol qui nous donne un meilleur bilan de liaison (càd rapport signal sur bruit).
Franchement, j'ai des difficultés pour réaliser la partie trace au sol, c'est exactement comme solstice et orbitron.
Donc voici mon sujet.

Il existe un programme pour visualiser la trace au sol et qui fonctionne en DOS. Il s'agit de STSPLUS que l'on peut trouver à l'adresse http://celestrak.com/software/dransom/stsplus.html

On peut récupérer sur le site également les éléments 2 lignes (TLE) mis à jour régulièrement par le NORAD. C'est ce que j'utilise pour regarder l'ISS par exemple. Le programme permet de prévoir les passages visible à l'oeil nu mais aussi tous les autres passages et calcule le doppler si tu veux écouter les fréquences radioamateur de l'ISS par exemple. Evidemment ce n'est pas aussi "sexy" qu'un programme windows mais c'est très efficace.

J'ajoute mon cent à cette histoire qui n'est pas si simple :

Cette formule, approximative, va te permettre de calculer pour une hauteur donnée d'un récepteur et une autre hauteur donnée d'un émetteur
la distance où le contact radio peut s'établir. Je dis contact radio mais c'est aussi valable pour un contact visuel.

Dnm = 1.23 (\2/ Hr + \2/ He)

Avec Distance en miles nautiques Dnm
Racine carrée de Hr hauteur en feet du récepteur,
Racine carrée de He hauteur en feet de l'émetteur,

Ce qui te donne en exemple la couverture radio de l'ISS à 350 km de distance du sol :

350 km = 350.000 m ètres, soit 1.050.000 feet

Cela fait, traduit en km, un rayon radio de 2200 km ; c'est le rayon du cercle que tu vois sur Orbitron
qui entoure l'ISS sur la carte géographique. C'est la zone ou un contact radio ou visuel (si les conditions
d'éclairage sont réunies) peut être espéré .

J'ai tourné au tour du travail de Kelso (thèse écrite pour le Fortran), ce n'est pas trivial, même si on
aime les math, il faut être bon. Pourtant c'est le formulaire le plus simple (sic) ; c'est celui qui, à partir des
Two Lines (TLE), permet de calculer les éphémérides d'une part et peux d'autre part te donner les coordonnées
géographiques du point survolé par un satellite. Si tu sais projeter ça sur une carte géographique alors tu as
ORBITRON.

Maintenant si tu veux faire simple, ORBITRON est gratos pour MS Windows, tu le trouveras sur Internet.
Je l'utilise, et je ne suis pas le seul. Il y en a plein d'autres sans tomber dans STK de AGI qui est complexe,
payant, mais super bien, pour autant que je m'en souvienne.

Bon appétit :sage: