Re: Lancement Antares - Cygnus.1 - 18-09-2013

**montmein69** Donateur Messages : 20962 Inscrit le : 01/10/2005

NSF parle aussi d'un problème de GPS :

NasaSpaceFlight a écrit:
Orbital’s Cygnus spacecraft was into the final leg of berthing with the International Space Station (ISS) on Sunday morning, prior to a problem with the spacecraft’s GPS.

Griffon a écrit:Report du RdV à Mardi ! Problème de GPS (différentiel ?) si j'ai bien compris.

Le premier échange de données entre ISS et Cygnus ne s'est pas passé correctement, causant une interruption de l'approche. La cause a été identifiée, et un patch logiciel sera téléchargé.
Il faut 48 heures pour réinitialiser la procédure d'approche.

source : http://www.orbital.com/Antares-Cygnus/

Report ne vaut pas annulation. Nous attendrons patiemment que le patch prenne corps et que Cygnus cause le langage de l'ISS.

Cela va me reposer les yeux car il y avait un bon moment que je m'efforcais de distinger qqchose de Cygnus sur les images que nous
renvoie l'ISS depuis ce matin.
A mardi donc.

Mardi 24 sera une date butoir, car le 25 c'est le décollage du Soyouz TMA-10M avec la relève d'équipage.
Il devrait alors avoir priorité sur le Cygnus.

Le patch sera installé et testé sur un simulateur sur Terre aujourd'hui. Si le test se passe bien, le correctif logiciel sera téléchargé sur le vaisseau Cygnus au cours de la nuit.

http://www.spaceflightnow.com/antares/cots1/status.html

**Sidjay** Messages : 17121 Inscrit le : 05/04/2009 Age : 43 Localisation : R.P

heu..juste une question.
A l'instar de Dragon, le vaisseau Cygnus utilise-t'il le système de navigation CUCU?:scratch:

Sidjay a écrit:heu..juste une question.
A l'instar de Dragon, le vaisseau Cygnus utilise-t'il le système de navigation CUCU?:scratch:

S'agit-il d'un système de navigation développé sous la direction de cette mathématicienne et informaticienne Liliana Cucu-Grosjean ?

**Sidjay** Messages : 17121 Inscrit le : 05/04/2009 Age : 43 Localisation : R.P

Giwa a écrit:
Sidjay a écrit:heu..juste une question.
A l'instar de Dragon, le vaisseau Cygnus utilise-t'il le système de navigation CUCU?:scratch:
S'agit-il d'un système de navigation développé sous la direction de cette mathématicienne et informaticienne Liliana Cucu-Grosjean ?

Le système "COTS UHF Communication Unit (CUCU)" avait été assemblé à ISS en 2009 par STS-129, en vue des futures missions de ravitaillement commerciales (COTS-CRS).
Par définition, je me répond tout seul...et en déduit que Cygnus utilise CUCU pour son approche vers ISS. Mais peut-etre me trompe-je....

**D'jo** Messages : 254 Inscrit le : 24/11/2007 Age : 34 Localisation : Québec

Nasaspaceflight a écrit:
This critical approach period is called Proximity Ops, with Cygnus using the JEM PROX system for direct communications with ISS, effectively resulting in the use of the same system Japan’s HTV uses for arriving at the ISS, as much as there will be a number of different settings employed for Cygnus’ arrival.'

Cygnus utilise le meme systeme de navigation gps que le HTV japonnais alors que Dragon utilise un autre systeme. Le probleme de dimanche serait du a un probleme de date entre Cygnus et l'ISS. Cygnus utiliserais un ancien format de date alors que l'ISS utilise une version plus recente. Un simple patch va corriger le probleme. Pour plus d'info: Nasaspaceflight. L'article est mise a jour durant la mission.

Sur le site d'OSC ils parlent de

discovery of a data format discrepancy between an on-board International Space Station (ISS) navigation system and a similar system on Cygnus

soit "incompatibilité de format de données" car data = données
Je ne sais pas si ces données concernent des dates ... ce n'est en tout cas pas précisé.

Je pense que D'jo ne doit pas être loin de la vérité car sur NSF, ils parlent de numéro de semaine au format de 10 bits et 13 bits

Compact GPS time was introduced in the late 90′s to save old hardware-based receivers that had 10-bit week number counters and were rolling over the GPS time “week number” – a problem similar to, but exactly, the “Y2K” issue. Modern GPS time uses a 13-bit week number

Orbital interpreted the PROX ICD as specifying that GPS time was transmitted using the 1980 ephemeris. Unfortunately, 1999 ephemeris data was received, which failed the Cygnus data integrity test.

http://forum.nasaspaceflight.com/index.php?topic=31845.120

edit: m'aurait étonné aussi qu'un québecois se trompe dans la langue de Shakespeare :D

Amarrage repoussé au samedi 28 septembre.
Cygnus reste en sureté en orbite de parking.

http://www.orbital.com/

Faudrait juste préciser que Cygnus va bien. Le délai est dû à l'arrivée du Soyuz mercredi prochain.

Spaceman a écrit:Faudrait juste préciser que Cygnus va bien. Le délai est dû à l'arrivée du Soyuz mercredi prochain.

tout à fait et si cela n'avait pas été le cas, je l'aurais précisé ;)

Et accessoirement cela leur donne plus de temps pour terminer les vérifications sur les "formats de données" que doivent s'échanger la station et le Cygnus.
N'oublions pas que c'est un vol "test" et que c'est fait pour débusquer les "gremlins" qui pourraient se cacher

**D'jo** Messages : 254 Inscrit le : 24/11/2007 Age : 34 Localisation : Québec

Selon NFS, la source du probleme est une difference dans le compte des semaines. Le programme de l'iss debute le compte en 1999 alors que Cygnus debute en 1980. Pour corriger le probleme, il suffit d'ajoute 1024 semaines au donnee recu de l'iss. C'est pour sa que je parlais d'un probleme de date mais donnee comme dit montmein est plus exact. Jai simplifier ma traduction au maximum desoler.

Si on se réfère au message de wakka il était question d'un formatage sur 13 bits vs un formatage sur 10 bits (d'au moins une donnée ???? le numéro de semaine ? ) qui aurait fait "dérailler" la procédure de "vérification" ????

Modern GPS time uses a 13-bit week number
old hardware-based receivers that had 10-bit week number
which failed the Cygnus data integrity test.

Mais cette information n'est peut-être plus valide ? Ou bien il y a les deux causes ????

Les 2 problèmes ne sont en fait qu'un seul et unique problème:
l'ancien formatage GPS sur 10 bits, ne permettait de compter les semaines que jusqu'à 1024 !!! (1024 = 2 puissance 10). Comme il y a 52 semaines dans une année, 1024 semaines font un peu plus que 19 ans. Si on commence à numéroter les semaines à partir de 1980, 19 ans plus tard (plus précisément ~19,6 ans plus tard, donc en 1999), on retombait sur... zéro puis on recommençait à compter !
Impossible donc de distinguer entre la première semaine de janvier 1980, et la première semaine 'suivante' tombant vers août ou septembre 1999). C'est effectivement le même problème que le fameux "bug de l'an 2000" (on comptait les années sur 2 chiffres dans beaucoup de programmes... ce qui rendait indistinguable l'année 1900 [=00] de l'année 2000 [= aussi 00]).
D'où la nouvelle norme consistant à formater le numéro de semaine sur 13 bits (on peut alors aller jusqu'à 8192 semaines - 8 fois plus - donc on 'tient' 157 ans avant de retomber sur zéro!).

Pour ceux qui veulent tous les détails, voir: http://www.colorado.edu/geography/gcraft/notes/gps/gpseow.htm sur le problème de conversion des programmes GPS semaine-10 bits vers et depuis les programmes GPS semaine-13bits.

Et comme d'hab, la "mine" sur GPS qu'est http://en.wikipedia.org/wiki/GPS_signals (malheureusement non traduite en français... s'il y a des volontaires, Wikipedia appréciera certainement :) !)

scorpio711 a écrit:Les 2 problèmes ne sont en fait qu'un seul et unique problème:
l'ancien formatage GPS sur 10 bits, ne permettait de compter les semaines que jusqu'à 1024 !!! (1024 = 2 puissance 10). Comme il y a 52 semaines dans une année, 1024 semaines font un peu plus que 19 ans. Si on commence à numéroter les semaines à partir de 1980, 19 ans plus tard (plus précisément ~19,6 ans plus tard, donc en 1999), on retombait sur... zéro puis on recommençait à compter !
Impossible donc de distinguer entre la première semaine de janvier 1980, et la première semaine 'suivante' tombant vers août ou septembre 1999). C'est effectivement le même problème que le fameux "bug de l'an 2000" (on comptait les années sur 2 chiffres dans beaucoup de programmes... ce qui rendait indistinguable l'année 1900 [=00] de l'année 2000 [= aussi 00]).
D'où la nouvelle norme consistant à formater le numéro de semaine sur 13 bits (on peut alors aller jusqu'à 8192 semaines - 8 fois plus - donc on 'tient' 157 ans avant de retomber sur zéro!).

Pour ceux qui veulent tous les détails, voir: http://www.colorado.edu/geography/gcraft/notes/gps/gpseow.htm sur le problème de conversion des programmes GPS semaine-10 bits vers et depuis les programmes GPS semaine-13bits.

Et comme d'hab, la "mine" sur GPS qu'est http://en.wikipedia.org/wiki/GPS_signals (malheureusement non traduite en français... s'il y a des volontaires, Wikipedia appréciera certainement :) !)

A l'heure actuelle, ça me parait incroyable qui'on chipote encore sur 2 ou 3 bits, alors que les débits et les capacités mémoire ne sont plus ceux de 1970 !
Ils pouvaient pas mettre le nombre de semaines sur entier 32 bits, que gèrent toutes les machines depuis 20 ans ?

En fait, pour certains types de données, on chipote effectivement sur la taille des données au bit près: particulièrement lorsqu'on doit transmettre et/ou recevoir des données à très haut débit (par exemple envoyer des données toutes les millisecondes... ce qui est parfois d'ailleurs considéré comme du "pas si haut débit" maintenant :shock: ! Dans l'industrie financière, où je travaille, on atteint des débits de diffusion de données qui dépassent en pointe le million de messages par seconde, avec des latences inférieures à 50 microsecondes: quand on peut gagner quelques octets et même quelques bits sur la taille du message, on le fait).
Ou alors lorsqu'on a de fortes limitations en bande passante (par exemple émission à 50 bits par seconde).
Il y a pas mal d'infos intéressantes sur l'article de Wikipedia que j'ai cité précédemment, qui permettent de comprendre un peu mieux le pourquoi du comment... mais ça reste très technique.
Je ne vais pas détailler outre mesure, ça sortirait du sujet de ce fil... et ça barberait sans doute un grand nombre de lecteurs :roll: :) !

Oui, mais si ajouter un bit te multiplie ta surface mémoire par deux, ce n'est pas rien à faire circuler un bit de plus (pire si c'est deux ou trois) surtout si ce n'était pas déjà prévu.
Que ce soit sur un bus parallèle ou sur un bus série et même si on travaille sur des trames ce n'est pas si simple. On s'en sort un peu avec la compression de données numériques,
mais il y a des limites à tout. Reste plus que la bande passante à élargir, mais là il faut jouer du transistor.

Amarrage de nouveau repoussé au dimanche 29 pour éviter tout conflit avec le Soyuz et pour avoir le temps de terminer tous les processus d'arrivée des 3 nouveaux occupants

The next attempt – per a call to the ISS crew – will not take place before Sunday, delayed again from a previous target of Saturday, so as to avoid conflicting with the arrival of the next Soyuz vehicle.

“Orbital and NASA together decided to postpone the approach, rendezvous, grapple and berthing operations of the Cygnus cargo logistics spacecraft with the International Space Station until after the upcoming Soyuz crew operations are complete. The Soyuz crew is due to arrive at the ISS very late on Wednesday, September 25,” noted an Orbital statement on Monday.

http://www.nasaspaceflight.com/2013/09/cygnus-cots-graduation-iss-berthing/

Astro-notes a écrit:Oui, mais si ajouter un bit te multiplie ta surface mémoire par deux, ce n'est pas rien à faire circuler un bit de plus (pire si c'est deux ou trois) surtout si ce n'était pas déjà prévu.

De toute façon, une mémorie de 13 bits, ça n'existe pas : tous les registres sont en puissance de 2, donc 16 bits dans le cas qui nous occupe.
Une fois en mémoire, ou bien ya 3 bits inutilisés, ou bien ils ont réussi à y caser des flags, ou une valeurs sur 3 bits (un CRC par exemple).

Maintenant, pour un transfert de données, 3 bits en plus sur 13, c'est pas ça qui va casser tout le protocole de transmission de données.

Je pense qu'il s'agit surtout d'un héritage d'une techno vielle de 30 ans, et encore limité par les limitations de l'époque.

Certes, Akwa tu as globalement raison, mais bien entendu il y a toujours des cas particuliers comme les processeurs 12 bits
duodécimal (Digital Equipment Corp) et les montages exotiques avec certes des registres 4 ou 8 bits mais montés en parallèle
en nombre impair pour faire des mots qui ne sont pas des puissances de deux.
Dans le problème qui retient notre attention, j'ai du mal à comprendre qu'un montage numérique de 2013 (moins le temps d'étude)
en arrive à devoir passer de 10 bits à 13 bits pour être conforme. Si cela avait un sens au passage 1999 > 2000, j'ai du mal a comprendre
maintenant. Bon, mais comme vous le dites tous, il n'y a qu'a patcher, mais ça fait désordre.

La capture est prévue dimanche 29/09 à 11h15 GMT

Superbe! Cela nous promet un Dimanche chargé, avec le lancement prévu de la nouvelle Falcon-9 quelques heures aprés.

Dim 22 Sep 2013 - 10:22

Dim 22 Sep 2013 - 10:46

Dim 22 Sep 2013 - 12:05

Dim 22 Sep 2013 - 20:02

Dim 22 Sep 2013 - 20:27

Dim 22 Sep 2013 - 23:39

Lun 23 Sep 2013 - 0:06

Lun 23 Sep 2013 - 0:10

Lun 23 Sep 2013 - 2:58

Lun 23 Sep 2013 - 11:21

Lun 23 Sep 2013 - 11:50

Lun 23 Sep 2013 - 16:12

Lun 23 Sep 2013 - 18:00

Lun 23 Sep 2013 - 18:22

Lun 23 Sep 2013 - 19:48

Lun 23 Sep 2013 - 22:13

Mar 24 Sep 2013 - 20:12

Mar 24 Sep 2013 - 20:58

Mar 24 Sep 2013 - 22:22

Mer 25 Sep 2013 - 0:13

Mer 25 Sep 2013 - 11:45

Mer 25 Sep 2013 - 15:10

Mer 25 Sep 2013 - 16:14

Mer 25 Sep 2013 - 17:36

Sam 28 Sep 2013 - 9:36

Sam 28 Sep 2013 - 10:37