[cssm] DDOR Scan Pattern format proposal
Martin.Unal at esa.int
Martin.Unal at esa.int
Tue Aug 25 08:25:56 UTC 2020
Hello
The differences, elaborated as comments in the XML instance document, are:
1. Removal of the service indication as the DDOR service would
already be indicated in the SMURF
OK - redundant information shall be removed
2. Removal of the account of scan targets as each target has an
ordinal number assigned to it so it is quite trivial to determine the
number of targets if that is needed (and less error-prone)
OK - redundant information shall be removed
3. addition of a reference to the carrier configuration profile for
the spacecraft(s) participating in the DDOR observation (in turn this will
indicate the frequency band as well as provide information for the DOR
tones from the spacecraft(s))
OK - I suggest to group the targets description at the start.
This to remove all possibility to have inconstent data.
Target description shall point to the SANA name, may include the relevant
"flux" or configuration ("carrierRef") information
DDOR target per scan only refers to the target named defined to remove
redundant information (possibly inconsistent) in each call
4. The absolute start time for the scan pattern has been added --
this will help to verify that the scan pattern time fits with the set of
activities scheduled
Where are defined the "activity times" ? If the information is already
present in the SMURF or in the service package, it shall not be present
again in the DDOR description. Otherwise each team will look at different
value, inconsistence will not be detected and service will be lost.
5. a slew time that can be stated for each target rather than a
uniform slew time ? this may allow for optimization such that a DDOR
measurement that could not be achieved via fixed slew times can be
achieved if the overall amount of time spent slewing is reduced (of course
this would be subject to negotiation, but the purpose here is to allow for
expression of the information and not to specify behavior)
I disagree. The DDOR service description has to specify the behaviour.
DDOR is typically a service which can be implemented by multiple party. If
you give freedom on the slew time, one will optimise the slew, the other
not. Measurement will be taken at different times and correlation will not
be possible.
What the point of optimising 30s per slew ? I don't believe 5 minute extra
have ever prevented feasibility of a DDOR. Low benefit, high cost.
"optional" items are cost and complexity drivers for the implementation.
If you say you need it, it shall be present all the time. Otherwise,
better drop it.
Here is a xml view of my proposal. I have left a "slew per scan" attribute
and the absoluteStartTime for the discussion.
Regards
________________________________________
Martin UNAL
Ground Operation Manager
Ground Facilities Ops HSO - ONO
H-376
ESOC
Robert-Bosch Strasse 5
64 293 Darmstadt
Germany
Tel +49 6151 90 2959
________________________________________
From: "Barkley, Erik J (US 3970)" <erik.j.barkley at jpl.nasa.gov>
To: "EXTERNAL-Unal, Martin P (9110-Affiliate)" <Martin.Unal at esa.int>
Cc: "CCSDS Service Mgmt WG" <smwg at mailman.ccsds.org>, "Border, James S
(US 335D)" <james.s.border at jpl.nasa.gov>
Date: 16/07/2020 23:32
Subject: DDOR Scan Pattern format proposal
Hello Martin (and my apologies for the earlier incorrect spelling),
The DDOR WG Chair (Jim Border) and I have had an exchange with regard to
the proposed scan pattern for inclusion in the SMURF. Attached please
find a proposed scan pattern format -- a sample XML instance document and
a pictorial representation. This is largely based on the pattern you have
proposed.
The differences, elaborated as comments in the XML instance document, are:
1. Removal of the service indication as the DDOR service would
already be indicated in the SMURF
2. Removal of the account of scan targets as each target has an
ordinal number assigned to it so it is quite trivial to determine the
number of targets if that is needed (and less error-prone)
3. addition of a reference to the carrier configuration profile for
the spacecraft(s) participating in the DDOR observation (in turn this will
indicate the frequency band as well as provide information for the DOR
tones from the spacecraft(s))
4. The absolute start time for the scan pattern has been added --
this will help to verify that the scan pattern time fits with the set of
activities scheduled
5. a slew time that can be stated for each target rather than a
uniform slew time ? this may allow for optimization such that a DDOR
measurement that could not be achieved via fixed slew times can be
achieved if the overall amount of time spent slewing is reduced (of course
this would be subject to negotiation, but the purpose here is to allow for
expression of the information and not to specify behavior)
My sense is that we are close to a very good workable format. I look
forward to your comments.
Best regards,
-Erik
From: Martin.Unal at esa.int <Martin.Unal at esa.int>
Sent: Wednesday, June 17, 2020 06:29
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>
Cc: CCSDS Service Mgmt WG <smwg at mailman.ccsds.org>
Subject: RE: [EXTERNAL] Re: [cssm] Fw: DDOR configuration template
Hello
I will join late the telecon today. I should be able to make it for the
DDOR item in your agenda at 17H55 CET.
I have inserted my answer in colour in your text.
We have been practicing DDOR support for years, internal ESA and cross
agency support. implementation. We have a unique sequence of event
template, we use standardise file naming convention for the raw data. It
is simple and it works. I am reluctant to the idea of increasing
complexity unless their is a benefit.
I see the DOR tones on/off times as part of the event sequence (which
references the configuration profile). Also, from local conversation, it
appears that name of the raw observation files matters for processing by
the correlators. That could also go in the configuration profile.
- The time pattern is changing frequently for DDOR. If you want to have an
event sequence for each, you will have to create one for nearly each new
support. It may be nice at conceptual level, but is a burden in operation.
I recommend the approach to have a single DDOR sequence, with durations as
parameters.
- The raw observation file name is not part of the request in the
recommended practice CCSDS 506.0-M-2. File name of navigation product
matters for processing, but that's covered in the relevant standard books.
Does it really make sense to leave freedom to the user to select the file
name of the result in a booking request ? The same logic would then
applies to all navigation product. Do you consider leaving a file name
entry for ranging, Doppler, meteo and so on... .
I see the scan pattern as being part of the SMURF -- a question I have
here is whether or not the scan pattern can be template-a-sized such that
it is always referred to by some sort of identifier. My sense from the DSN
side is that this is not the case as the quasar(s) being utilized very
depending upon the mission trajectory etc. I think it will be interesting
to discuss further on this at the teleconference tomorrow if you're
available.
- The Quasars to be used change for each DDOR request. In our
implementation the Quasar name are anonymized to Q1/Q2/Q3, depending of
how many Quasar are requested in a given support. It is up to the
requester to provide the orbital predicts of the real Quasar under the
relevant code name.
Regards
________________________________________
MarCin UNAL :)
Ground Operation Manager
Ground Facilities Ops HSO - ONO
H-376
ESOC
Robert-Bosch Strasse 5
64 293 Darmstadt
Germany
Tel +49 6151 90 2959
________________________________________
From: "Barkley, Erik J (US 3970)" <erik.j.barkley at jpl.nasa.gov>
To: "EXTERNAL-Unal, Martin P (9110-Affiliate)" <Martin.Unal at esa.int
>
Cc: "CCSDS Service Mgmt WG" <smwg at mailman.ccsds.org>
Date: 17/06/2020 00:02
Subject: RE: [EXTERNAL] Re: [cssm] Fw: DDOR configuration template
Hello Marcin,
Here are some quick responses as to how I think this likely fits within
the service management.
I see the DOR tones as being part of the configuration profile.
I see the DOR tones on/off times as part of the event sequence (which
references the configuration profile). Also, from local conversation, it
appears that name of the raw observation files matters for processing by
the correlators. That could also go in the configuration profile.
I see the scan pattern as being part of the SMURF -- a question I have
here is whether or not the scan pattern can be template-a-sized such that
it is always referred to by some sort of identifier. My sense from the DSN
side is that this is not the case as the quasar(s) being utilized very
depending upon the mission trajectory etc. I think it will be interesting
to discuss further on this at the teleconference tomorrow if you're
available.
Best regards,
-Erik
From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of
Martin.Unal at esa.int
Sent: Wednesday, May 27, 2020 01:26
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>
Cc: CCSDS Service Mgmt WG <smwg at mailman.ccsds.org>
Subject: [EXTERNAL] Re: [cssm] Fw: DDOR configuration template
Hello
Here is a version 2 based on yesterday telecon discussion.
I have changed the configuration item names to ddor_configuration and
spacecraft_configuration.
<configuration_profile service="deltaDor">
<!-- DDOR configuration element defines which type of DDOR configurarion
shall be used to configure the ground station -->
<!-- This can be used to select which type of tones to be used, how many
DL band,...-->
<!-- The attribute and their value will probably be provider specific -->
<ddor_configuration name="DDOR1"/>
<!-- The spacecraft_configuration can be used to convey information
relevant for the station configuration on a per DL basis (if needed)-->
<!-- To be open to future multi band DDOR, It is suggest to have an
dlIndex-->
<!-- The attribute and their value will probably be provider specific -->
<spacecraft_configuration dlIndex="1" band="Xband" transmitter="1"/>
The main part to agree with the DDOR team concern the DDOR parameter. They
are not really concerned by the configuration aspect. This is more an
issue between the flight control team and the provider.
I am still not sure where you want to have it in a SMURF request.
Will it be in provider specific parameter ? In the configuration profile
(902x05-Simple-conf-profile-Mission-Agrt) ?
Regards
________________________________________
Martin UNAL
Ground Operation Manager
Ground Facilities Ops HSO - ONO
H-376
ESOC
Robert-Bosch Strasse 5
64 293 Darmstadt
Germany
Tel +49 6151 90 2959
________________________________________
This message is intended only for the recipient(s) named above. It may
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA
Data Protection Officer (dpo at esa.int).
This message is intended only for the recipient(s) named above. It may
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA
Data Protection Officer (dpo at esa.int).[attachment
"ProposedDDOR-ScanPatternFormat-eb-16Jul20.xml" deleted by Martin
Unal/esoc/ESA] [attachment "ProposedScanPatternFormat-eb-16Jul20.pptx"
deleted by Martin Unal/esoc/ESA]
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200825/283b6e04/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DDOR-request-element-v4.xml
Type: application/octet-stream
Size: 2712 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20200825/283b6e04/attachment-0001.obj>
More information about the SMWG
mailing list