Level 0 : Telemetry download
SDTP Configuration file
Bepi Colombo telemetry download use a library called SDTP furnished par Jaxa (libstdp-1.0.3), that needs a configuration file to define various servers to download telemetry
The library comes with a Japaneese documentation, but no English translation could be found.
The configuration file used by SDTP library is defined by the following variable:
export TLMPATH=/home/bepi/trunk/config/SOCKFILE.X.oridst 10000 010e07110000 010e01020601 133.74.4.2
stg 20000 010e07110000 010e06010000 133.74.4.2
#
# sir 30200 998877665544 999999999999 133.74.196.2
#We don’t fully understand the content of this configuration file.
Looking at the source code of libsdtp, it seems that :
-
dst : server used to connect when using SDT_TLMONLINE
-
stg : server used to connect when using SDT_TLMRATE
-
sir : server used to connect when using SIRIUS mode
Questions
-
Could we have a description of this config file ?
-
What are the IP of servers we have to use ?
-
What will be the IP in the future ?
-
What are the other parameters (5 parameters per line) ?
-
What is SIRIUS mode ?
-
What is the IP of the SIRIUS server ? Is it in use actually ?
Downloading telemetry
We are using a shell script, called DOWNLOAD, which is using another C language software, GET_DATA, which is calling the SDTP library to connect to JAXA’s servers and download data.
There are a lot of parameters to specify to download data :
MODE
-
Mode = 1 : Real time
-
Mode = 2 : Late buffer
|
we are actually using only MODE = 2 to download data. |
Looking in the source code of SDTP library, we could see that another MODE (SIRIUS_MODE = 3) is available.
If using SIRIUS mode, it seems possible to use a list of couples (Antenna, Band), whereas when using dst or stg servers, we can only specifiy one couple (antenna, band).
We couln’t get it works.
-
Is the SIRUS mode available ?
-
What is the IP of the SIRIUS server ?
TYPE
-
TYPE = 1 : Path (not used)
-
TYPE = 2 : Time
Need to specify :
-
START_TIME=yyyymmdd000000
-
END_TIME=yyyymmdd235959
-
TIME KIND
-
TIME_KIND = 1 : Received time
-
TIME_KIND = 2 : Generation time
-
TIME_KIND = 2 : it seems it doesn’t work (error = -20013)
-
What’s the real meaning of this parameter?
List of (APID, VCID)
-
MEA1 APID : 0x528, 0x628 (Science, HSK)
-
MEAD APID : 0x530, 0x730 (Science, HSK)
For each APID, we have to specify both:
-
VCID = 1 : Real
-
VCID = 2 : Repro
-
Is it necessary to specify VCID 1 and 2 for each APID ?
It seems that we will have to download and process separately Real Time and Reprocessed data, then merging the 2 sources if we want to ensure normal increasing time tag records.
(ANTENNA, BAND)
A couple of arguments (Antenna, Band)
Where bands should be:
BAND_S 0x40
BAND_X 0x80Some antennas ID should be found in JAXA’s examples :
0x11 KSC34M
0x20 USDC
0x82 SSOC-C
0x83 ???Problem
During the test in January and February 2017, we have to download data from both antennas 0x82 and 0x83, if we want to have full coverage of data.
Then, the had to merge two telemetry files, to put as input of L0 processing pipeline.
#
# 2017-01-26 MEA1
#
MEA1_L0_20170126_TLM_082.dat 57 KB
MEA1_L0_20170126_TLM_083.dat 199 KB
#
# 2017-01-26 MEA2
#
MEA2_L0_20170126_TLM_082.dat 21 KB
MEA2_L0_20170126_TLM_083.dat 130 KB
#
# 2017-01-28 MEA1
#
MEA1_L0_20170128_TLM_082.dat 435 KB
MEA1_L0_20170128_TLM_083.dat 0 KB
#
# 2017-01-28 MEA2
#
MEA2_L0_20170128_TLM_082.dat 404 KB
MEA2_L0_20170128_TLM_083.dat 0 KB
#
# 2017-02-03 MEA1
#
MEA1_L0_20170203_TLM_082.dat 4762 KB
MEA1_L0_20170203_TLM_083.dat 0 KB
#
# 2017-02-03 MEA2
#
MEA2_L0_20170203_TLM_082.dat 2150 KB
MEA2_L0_20170203_TLM_083.dat 0 KB
#
# 2017-02-04 MEA1
#
MEA1_L0_20170204_TLM_082.dat 0 KB
MEA1_L0_20170204_TLM_083.dat 697 KB
#
# 2017-02-04 MEA2
#
MEA2_L0_20170204_TLM_083.dat 677 KBQuestions
-
Were can we find some informations about the antennas used ?
-
We could miss data, if another antenna is used
H0 mode
We found description of data products send in H0 mode, but we could’nt find anymore information about it.
-
How to download and recognize H0 mode data ?
-
Is there some data available for this mode during the previous tests ?
Memory DUMP
We had problem during the last tests in january/february, to download memory dump data.
We were thinking that there was a different APID to download memory dump data for each instrument (MEA1, MEA2).
We found in JAXA’s documentation that we have to use APID = 0x718 to download memory dump data, for all instrument handleded by MDP1 (MEA1, MEA2, MIA, …)
See : page=telemetry#MEMDUMP
Each memory dump telemetry packet starts with an header, where we can find the NODE_ID of the instrument :
0x05 : MEA1
0x06 : MEA2
0x07 : MIASOLVED: We can extract only the memory dump for our instruments, using this NODE_ID field.
Level 1 : production of raw data CDF
Time tagging
We had problems to compute time-tags for science data products, as the only information available is TI0 counter, given in 1/512 s, but we don’t know the origin of this counter.
We find an algorithm that seems to work fine most of the time, but we found some problems for a couple of days.
See page=datation
Could you validate this algorithm?
Time tagging discrepancies
We found some discrepancies in time-tags for most of science data products (OMN, VM, PAP…).
This problem could be corrected on ground, but it would be good to have a look on the onboard software to investigate this problem.
See : page=bug-datation
Rather than getting data products regularly spaced with N seconds, depending on mode (LOW, MED, HIGH), we found sequences of :
N, N, N, N,+4, N-4, N, N, N, 2*N, 0, N, N...It seems there is a shift of one spin duration.
Examples :
This should be corrected on ground, with a specific algorithm, but it would be better to have a look on onboard software, to investigate how to solve this problem.
Data produts handling
We are now able to read all telemetry data products describe in JAXA’s document
Exception for H0 mode products, that we couldn’t find in telemetry.
Is there any HO data available?
Grouping CDF data products
Initially, we were thinking that we could merge in a same CDF file all products if they have the same data structure (1D, moments), for all modes Low, Med and High, just describing in CDF metadata the time validity of each record.
Giving for each record of VM products, either a start time and duration, either a center time and half interval, to describe records with a different periodiciy (16s, 8s, 4s).
Unfortunately, these products can be sent simultaneously, both in Low and Med or High mode, and it will be difficut to handle in a same file.
Eg: moments in LOW mode, with 16s resolution, will overall moments in MED or HIGH mode with 4s resolution.
We are now thinking to produce separate files for Low, Med and High mode, in order to avoid such recovery in time tags for various modes.
Level 2 : Physical values
Instrument geometry
We found some informations on anodes, efficiencies, … in A. Fedorov calibration report
Et-PAP behaviour
Et-PAP data are given in 4 (or 8) energy bands, defined each by a start number and a width, supposed to be given in range 0..31 (or 1..32)
2017-026T13:51:59.134437Z Energy bands = [0, 9, 15, 21, 27]
...
2017-026T14:24:34.953600Z Energy bands = [0, 0, 2, 4, 6]
...
2017-026T14:42:58.854800Z Energy bands = [0, 9, 15, 21, 27]
...Could you confirm use of values in range 0..31?
Moments
6 energy bands : first one corresponding to 2 * spacecraft potential, and the 5 next ones
We don’t really have enough time to look their behaviour in detail, just parsing the telemetry packets.
Physical values
We found a memo on MEA moments, explaining how ROM tables are generated, and how to recompute moments on ground.
And a C source code to convert VM to physical values :
Questions
-
What is the reference frame used to express velocity vectors?
-
Could we use as it is the conv_MEA.c software to convert to physical values ?
MEA2 3DH dataset
Data are given in 2 data products with same time tag:
-
data ID = 0 : CH 0-7 x 16 sectors
-
data ID = 1 : CH 8-15 x 16 sectors
Questions
-
Are anode numbering the same as used in A. Fedorov calibration report ?
-
We have to mix the first 8 sectors x CH 0-7 of data ID 0 and the first 8 sectors x CH 15-8 of data ID 1, to obtain the first 3D full distribution
-
In the same way, mix the last 8 sectors x CH 15-8 of data ID 1 and the last 8 sectors x CH 0-7 of data ID 0, to obtain the second 3D full distribution, 2 seconds later.
