LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

Installation du software le 09/02/2016
dans /opt/LFR/LFR-FSW/3.0.0.20 + renommage de l'exe sans l'extension 3-0-0-20
Adaptation des scripts pour utiliser cette version.

14h40 de NORMAL mode joués cette nuit. Les parametres utilisés sont ceux par défaut du normal mode. Le test s'est bien terminé

Premier test d'analyse sur les Snapshots à 300s et les CWF_F3 (vérifier si premiere salve de CWF_F3 correcte)

Les fichiers (2016_02_09_17_18_56*) sont pc-instru/weekly erased /Thomas/run-2016-02-09-3.0.0.20-1.1.89.

Les fichiers (2016_02_09_17_18_56*)sont rangés également sur pc-faust9 répertoire/ home/validation/data/R3/3.0.0.20/TESTCHARGE/normal.

En piece jointe le script /opt/VALIDATION_R3/test_modes.py joué
Contexte du test
---------------------
FSW 3.0.0.20
VHDL 1.1.89
Timegen 0.0.0.1
EM AVEC Timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee

Tests faits sur les SWF montrent une nette amélioration par rapport au premier test long #612
La logique de resynchronisation semble de nouveau maitrisée mais les amplitudes des oscillations sont 2 à 3 fois supérieures par rapport aux meilleurs tests précédents.

Super Paul pour toutes ces explications et cela n'est pas de trop! Effectivement on avance mais j'ai encore des questions :

1. Sur ta figure, "delta_snapshot + 2 x correction" signifie t-il bien "delta_snapshot += correctionInt" (cf le code de applyCorrection) ? De sorte que ce que tu appelles la valeur nominale de delta_snapshot est en fait sa valeur avant l'application d'une correction (le coup d'avant)? Ou de fait la valeur nominale est la valeur initiale que tu nommes delta_f2 ? Cela est important car si la dérive est bien supérieure à T2 on sera toujours en retard ou en avance (par manque d'adaptation à la situation courante puisque delta_f2 est fixé à l'avance). Aussi quand tu écris sur la figure " + 2 x correction" c'est dans le cas seulement où "correctionInt" vaut cette valeur, non ?
   Le fait que tu appliques "2 x correction" c'est bien parce que la prise en compte ne sera effective que dans 2 coups (2 dérives qui se seront accumulées depuis la mesure de "correction")?
2. Dans le cas d'une correction négative il me semble que tu as codé une boulette : dans "( (correction < -1.) && (correction < -0.5) )" tu voulais certainement écrire "( -1. < correction)", non ? Jusqu'à présent nous avions des corrections positives à faire je crois (dérive négative) de sorte que cette coquille n'aurait pas été détectée ...
3. dans le bloc CORRECTION, à quoi sert la ligne "computeCorrection( timePtr );" qui n'affecte aucune valeur ?
4. Une suggestion naïve: remplacer floor par ceil dans le cas d'une correction positive et inversement ceil par floor dans le cas opposé ? As-tu déjà essayé? Dans mon intuition j'imagine que cela correspondrait à une correction plus efficace (i.e. qui nous ramène plus près d'une sharp seconde). Mais cela est peut-être instable ...

Merci encore pour ton boulot!

1. la valeur delta_f2 est utilisée une seule fois au démarrage pour décompter le temps jusqu'au départ du premier snapshot à f2. Ensuite, le compteur est rechargé avec la valeur delta_snapshot_init (valeur nominale) ou delta_snapshot_init + correctionInt. delta_snapshot_init est la valeur nominale que devrait avoir delta_snapshot si il n'y avait pas de dérive. Effectivement, le x2 vient du fait que la dérive est double entre le moment où on utilise delta_snapshot_init et le moment où on utilise la correction
2. tout à fait d'accord avec la remarque. Halala, c'est dur ce passage du code. Je fais le correction!
3. le bloc computeCorrection me sert juste à faire des printf indicatifs pour le debug, la valeur n'est pas utilisée
4. une suggestion intéressante mais j'ai effectivement eu des cas instables au cours du développement alors j'ai mis la solution avec l'intervalle 0.5-1 qui permet d'appliquer une correction un peu en avance, avant que la dérive ne soit supérieure à un T2

Hello Paul, je suis en train d'analyser le dernier test long en date (#618), je vais a priori vous sortir des résultats tout à fait similaires à ceux d'ici. Par contre je n'arrive pas vraiment encore à coller ton algorithme sur les courbes d'écart observées. Donc encore une question pour éclaircir ma lanterne:
- comment fixes-tu la valeur nominale delta_snapshot_init ? Cette valeur ne change t-elle plus jamais ?

On récupère le paramètre sy_lfr_n_swf_p dans les paquets ou on prend la valeur par défaut (300s) puis j'applique la fonction suivante pour mettre à jour le paramètre utilisé par le VHDH

void set_wfp_delta_snapshot( void )
{
    /** This function sets the delta_snapshot register of the waveform picker module.
     *
     * The value is read from two (unsigned char) of the parameter_dump_packet structure:
     * - sy_lfr_n_swf_p[0]
     * - sy_lfr_n_swf_p[1]
     *
     */

    unsigned int delta_snapshot;
    unsigned int delta_snapshot_in_T2;

    delta_snapshot = parameter_dump_packet.sy_lfr_n_swf_p[0]*256
            + parameter_dump_packet.sy_lfr_n_swf_p[1];

    delta_snapshot_in_T2 = delta_snapshot * 256;
    waveform_picker_regs->delta_snapshot = delta_snapshot_in_T2 - 1;    // max 4 bytes
}