Bug #418
closed
données BP2 complètement fausses (en mode SBM2 et échantillonange à F1)
Added by thomas chust over 9 years ago.
Updated over 9 years ago.
Description
Lors du test ctc-12 (96 enregistrements en SBM2 avec 6 signaux sinusoïdaux injectés simultanément avec des fréquences allant de 7 à 102 Hz et des amplitudes de 2V pp) les fichiers 2015_04_23_hh_mm_ss_packet_record_SBM2.2f1 sont tous identiques (!?) avec des valeurs incohérentes par rapport aux signaux injectés. Par exemple la valeur de la données auto B1B1* de la première fréquence vaut: 1736040064.0000000000000000 ce qui est énorme (correspondrait à environ 4.6 V).
Conclusion: il y a un problème soit dans la décom (=> Bruno) soit dans le soft de vol (=> Paul); voire dans le VHDL (=> J-C) ?
Le pb a été constaté avec les config suivantes :
- VHDL 1.1.68 + FSW 2.2.3
- VHDL 2.1.83 + FSW 2.2.3
- VHDL 1.1.83 + FSW 3.0.0
Files
ctc012_2015_04_23-14_31_50.pdf (130 KB)
ctc012_2015_04_23-14_31_50.pdf |
|
thomas chust, 15/05/2015 03:05 PM
|
|
summary.txt (5.25 KB)
summary.txt |
|
thomas chust, 15/05/2015 03:08 PM
|
|
2015_04_23_15_32_49_packet_record_SBM2.cf2 (393 KB)
2015_04_23_15_32_49_packet_record_SBM2.cf2 |
|
thomas chust, 15/05/2015 03:11 PM
|
|
2015_04_23_15_32_49_packet_record_SBM2.2f1 (126 KB)
2015_04_23_15_32_49_packet_record_SBM2.2f1 |
|
thomas chust, 15/05/2015 03:11 PM
|
|
2015_04_23_15_32_49_packet_record_NORMAL.sf2 (101 KB)
2015_04_23_15_32_49_packet_record_NORMAL.sf2 |
|
thomas chust, 15/05/2015 03:11 PM
|
|
2015_04_23_15_32_49_packet_record_NORMAL.sf1 (101 KB)
2015_04_23_15_32_49_packet_record_NORMAL.sf1 |
|
thomas chust, 15/05/2015 03:11 PM
|
|
2015_04_23_15_32_49_packet_record_NORMAL.af2 (437 KB)
2015_04_23_15_32_49_packet_record_NORMAL.af2 |
|
thomas chust, 15/05/2015 03:11 PM
|
|
2015_04_23_15_32_49_packet_record_NORMAL.af1 (473 KB)
2015_04_23_15_32_49_packet_record_NORMAL.af1 |
|
thomas chust, 15/05/2015 03:11 PM
|
|
2015_04_23_15_32_49_packet_record_NORMAL.2f2 (8.47 KB)
2015_04_23_15_32_49_packet_record_NORMAL.2f2 |
|
thomas chust, 15/05/2015 03:11 PM
|
|
2015_04_23_15_32_49_packet_record_NORMAL.2f1 (9.16 KB)
2015_04_23_15_32_49_packet_record_NORMAL.2f1 |
|
thomas chust, 15/05/2015 03:11 PM
|
|
- Status changed from New to In Progress
- % Done changed from 0 to 10
Côté DECOM : c'est la même méthode qui traite les BP2 quel que soit le mode donc, à priori, pas possible d'avoir un traitement différent des BP2 selon le mode.
Je vais regarder directement les données en binaire dans le datadump en sortie de LFR AVANT décommutation afin de borner quand le problème survient.
VHDL 1.1.68
FSW 2.2.3
- Assignee changed from bruno katra to paul leroy
- Priority changed from Normal to High
- % Done changed from 10 to 20
Examen des datadump dans un editeur hexa : le pb est bien présent dans les datadump donc ce n'est pas un pb de DECOM.
J'ai regardé d'autres résultats en SBM2 : CTC-006, le même pb est présent = Tous les paquets BP2 à F1 contiennent le même set de valeurs (pas le même que ctc-012).
VHDL 1.1.68
FSW 2.2.3
- Project changed from DECOM LFR to LFR-FSW
Addendum Bruno : Il faut vérifier si le pb est aussi présent avec le VHDL 1.1.83 (flashé sur l'EQM) + FSW 3.x.
Test sur résultats ctc-012 sur EQM :
VHDL 2.1.83
FSW 2.2.3
Le pb est présent et encore plus caractéristique : tous les AUTO sont à 0.0000000002328306 et tous les CROSS à -1.000000
Pourrais-tu me donner une configuration de test où ça marchait ou bien ça n'a jamais marché?
Examen de résultats obtenues durant campagne de test pour les interfaces R3 :
VHDL 1.1.83
FSW 3.0.0.0
Le pb est présent.
- Description updated (diff)
paul leroy wrote:
Pourrais-tu me donner une configuration de test où ça marchait ou bien ça n'a jamais marché?
J'ai l'impression que ca n'a jamais marché (voir configs dans Description de cet issue)
Plus généralement, y a-t-il un mode dans lequel les BP2 fonctionnent? Il me semble qu'on avait fait un peu de mise au point avec Thomas en janvier sur les BP2 et que nous avions résolu quelques bugs.
paul leroy wrote:
Plus généralement, y a-t-il un mode dans lequel les BP2 fonctionnent? Il me semble qu'on avait fait un peu de mise au point avec Thomas en janvier sur les BP2 et que nous avions résolu quelques bugs.
Comme indiqué dans le titre, cette issue ne concerne que les BP2@F1 en SBM2. Les BP2 dans les autres modes et freq n'ont pas ce comportement.
OK, merci, ça devrait me faciliter le debug.
A ma connaissance tous les BP2 en NORMAL mode sont nominaux (comparaison avec les ASM cross et auto très cohérente).
- Status changed from In Progress to Resolved
- Assignee changed from paul leroy to bruno katra
fsw >= 3.0.0.2, bug identified and corrected
- Status changed from Resolved to Closed
- % Done changed from 20 to 100
Testé ok : pas de decom pour R3 donc examen des .csv généré par lfrcontrolplugin => les set de valeurs sont maintenant différents.
Le facteur qualitatif sera evalué plus tard au niveau calibration.
Also available in: Atom
PDF