PAS Engineering Mode
====================
== How to find Engineering Mode
Search for TC(203,130) : SWA TC PAS enter in engineering mode
----
$ SWA_TC $(ALL_TESTS -d) | grep "TC(203,130)"
----
[role="small"]
----
2018-10-26T07:36:59.000 OK 2018-10-26T07:38:39.375 ERR 4 TC(203,130) ZIA58852 SWA TC PAS enter in engineering mode
2018-11-05T16:15:45.500 OK 2018-11-05T16:17:25.875 ERR 4 TC(203,130) ZIA58852 SWA TC PAS enter in engineering mode
2018-11-16T14:34:58.875 OK 2018-11-16T14:36:39.251 ERR 4 TC(203,130) ZIA58852 SWA TC PAS enter in engineering mode
2018-11-16T14:44:25.626 OK 2018-11-16T14:46:45.250 OK 4 TC(203,130) ZIA58852 SWA TC PAS enter in engineering mode
2018-11-19T15:14:11.500 OK 2018-11-19T15:17:06.250 OK 4 TC(203,130) ZIA58852 SWA TC PAS enter in engineering mode
2018-11-21T13:15:05.750 OK 2018-11-21T13:18:25.250 OK 4 TC(203,130) ZIA58852 SWA TC PAS enter in engineering mode
2018-11-28T09:41:08.250 OK 2018-11-28T09:44:28.250 OK 4 TC(203,130) ZIA58852 SWA TC PAS enter in engineering mode
2019-05-02T19:36:52.626 OK 2019-05-02T19:40:11.250 OK 4 TC(203,130) ZIA58852 SWA TC PAS enter in engineering mode
2019-05-02T19:41:12.750 OK 2019-05-02T19:44:32.250 OK 4 TC(203,130) ZIA58852 SWA TC PAS enter in engineering mode
2019-06-04T13:05:18.375 OK 2019-06-04T13:06:58.750 ERR 4 TC(203,130) ZIA58852 SWA TC PAS enter in engineering mode
2019-06-04T13:09:38.375 OK 2019-06-04T13:11:18.750 ERR 4 TC(203,130) ZIA58852 SWA TC PAS enter in engineering mode
2019-06-07T16:44:15.375 OK 2019-06-07T16:47:11.250 OK 4 TC(203,130) ZIA58852 SWA TC PAS enter in engineering mode
----
* The first column shows TAR[S/F] timetags that corresponds approximatively to the start of Engineering mode
* The third column shows TEC[S/F] timetags, and approximatively the end of Engineering mode
=== Problems encountered
==== TECF Error
We got an TECF error for some cases (ERR in column 4) :
* 2018-10-26,
* 2018-11-05,
* 2018-11-16T14:34/14:36 (but 14:44/14:46 is OK)
* 2019-06-04
The TECF error correspond to
APID (99, 1) TM (1,8) SID = 43177 : SWA_PAS_RPW_TRIG
With an error code of : A8A9
==== Missing data
We miss data in other case :
* 2019-05-02 19:36:52/19:40:11
* 2019-05-02 19:41:12/19:44:32
[red]#No explanation found !#
See http://solarorbiter.irap.omp.eu/tests/aux/20190502/3d_data_descriptor.jpg[]
=== Available data
Very few days are available with PAS running engineering mode :
----
$ STATS -c $(ALL_TESTS -d) | grep "pas-3dt" | grep -v " 0 records"
99 records : /DATA/SOLAR/DATA/L1/20181116/solo_L1_swa-pas-3dt_20181116_V00.cdf
245 records : /DATA/SOLAR/DATA/L1/20181119/solo_L1_swa-pas-3dt_20181119_V00.cdf
478 records : /DATA/SOLAR/DATA/L1/20181121/solo_L1_swa-pas-3dt_20181121_V00.cdf
483 records : /DATA/SOLAR/DATA/L1/20181128/solo_L1_swa-pas-3dt_20181128_V00.cdf
249 records : /DATA/SOLAR/DATA/L1/20190607/solo_L1_swa-pas-3dt_20190607_V00.cdf
----
== Various behaviour
[cols="20%,80%"]
|====
| 2018-11-16 | 39 samples (K=4) generating 99 CDF records
| 2018-11-19 | 74 samples (K=4) generating 245 CDF records
| 2018-11-21 | 98 samples (K=5) generating 478 CDF records
| 2018-11-28 | 99 samples (K=5) generating 438 CDF records
| 2019-06-07 | 75 samples (K=4) generating 249 CDF records
|====
See Ascii dump of CDF contents :
* link:documents/Engineering-Mode/solo_L1_swa-pas-3dt_20181116.ascii[]
* link:documents/Engineering-Mode/solo_L1_swa-pas-3dt_20181119.ascii[]
* link:documents/Engineering-Mode/solo_L1_swa-pas-3dt_20181121.ascii[]
* link:documents/Engineering-Mode/solo_L1_swa-pas-3dt_20181128.ascii[]
* link:documents/Engineering-Mode/solo_L1_swa-pas-3dt_20190607.ascii[]
=== __2019/06/07__
This mode generates 75 samples (1..75), composed of 8,33 sequences of 9 samples :
- 1 full 3D
- 7 sub-samples with K = 4 (or more)
- 1 full 3D
Some samples are not correctly time-tagged.
We found a bug fix with :
----
if (((sample -1) % 9) > 1) coarse_time += 1s
----
=== Question to Andrei (not sent)
Sorry, that's french...
~~~~
Salut,
Je ne sais pas si ou quand tu auras ce mail, mais je voulais verifier ce probleme avec toi.
Je viens d'aller voir Wilfried au sujet des problems de datation en mode engineering, mais il ne semblait pas du tout au courant.
Il semble plutot dire que le probleme viendrait du DPU...
Tu m'avais dit il y a quelques mois, en mode Snapshot ou Burst, ou Trigger burst, de corriger la datation :
if (sample > 2) coarse_time += 1s;
Le probleme de datation a l'air plus complique pour le mode engineering du 2019/06/07 :
on a 75 SAMPLES, composes d'une suite de 8,33.. sequences de 9s :
Sequence 1 : 9 s
- 1 3D full range (K=1)
- 7 3D sub-range x K=1..4
- 1 3D full range (K=1)
Sequence 2 : 9 s
- 1 3D full
- 3 3D sub-range
- 1 3D full
etc...
On a 8 sequences de 9s completes = 8 x 9 = 72 (samples 1..72) + les 3 premiers samples de la sequence suivante (73..75)
Apparemment, il faut corriger les datations des 7 derniers samples de chaque sequence de 9s.
J'ai du corriger comme suit :
if (((sample -1) % 9) > 1) coarse_time += 1s
Ca correspond aux samples [3,9], puis [12,18], puis [21,27]...
Le 2018/11/16 on a le meme schema : 39 samples avec des sequences (1 full, 7 sub-range, 1 full)
Le 2018/11/19 aussi : 74 samples avec des sequences de 9s
Mais ce n'est pas le meme probleme pour les autres journees : on n'a pas toujours des dynamic sequence de 9 s (1 full + 7 + 1 full)
Le 2018/11/28, on a 74 samples :
- 1 full 3D (sample = 1)
- 32 sub-range
- 1 full 3D (sample = 34)
- 32 sub-range
- 1 full 3D (sample = 67)
Bref, il faudra affiner la correction de datation.
~~~~
