[Sls-rfm] [EXTERNAL] Re: CCSDS 401 structure naming convention - proposed changes
Gian.Paolo.Calzolari at esa.int
Gian.Paolo.Calzolari at esa.int
Fri Apr 9 06:18:23 UTC 2021
Sorry, Jon.
The reply below was not to your mail. Please ignore.
I think that considering the terms generic and historical (amd explaining
this in a note) would be a good approach.
Regards
Gian Paolo
From: Gian.Paolo.Calzolari at esa.int
To: "Jon Hamkins" <Jon.Hamkins at jpl.caltech.edu>
Cc: sls-rfm at mailman.ccsds.org
Date: 08-04-21 23:13
Subject: Re: [Sls-rfm] [EXTERNAL] Re: CCSDS 401 structure naming
convention - proposed changes
Sent by: "SLS-RFM" <sls-rfm-bounces at mailman.ccsds.org>
No. I am not proposing this
Sent from my iPhone
On 8. Apr 2021, at 22:58, Jon Hamkins <Jon.Hamkins at jpl.caltech.edu> wrote:
I think of "telemetry" as a generic term which does not necessarily imply
the type of data or its direction (but it could, based on context or
historical convention). For example, in the optical coding standard the
title "HPE telemetry signaling" is used for a section describing one type
of optical code+modulation. The data can be anything as long as it is put
in Transfer Frames, and the direction can be forward or return.
----Jon
Jon Hamkins
Chief Technologist, Communications, Tracking, and Radar Division
O 818-354-4764 (preferred) | M 626-658-6220 (does not work at home)
JPL | jpl.nasa.gov
On 4/8/2021 1:15 PM, Gian.Paolo.Calzolari at esa.int wrote:
Again,
why should a modulation care whether the bits are from a USLP
Frame or something else?
I find true the reverse, who is deciding between TM/AOS/USLP Frames may do
a choice or another depending on the technology available.
As well, considering your correct statement "An Earth based receiver can
be much more complicated than a space based receiver." it is also true
that if you simply call that link a return link the receiver could also be
in space. Then are you really simplifying the matter?
About name changes, I keep my preference for NOTES inserted where needed
with more efficiency and less effort with respect to the side effect to
checked within the document and outside the document (e..g people used to
some terminology getting confused, references screwed up etc etc)
My cent
Gian Paolo
From: "Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND
APPLICATIONS INC]" <victor.j.sank at nasa.gov>
To: "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Cc: "sls-rfm at mailman.ccsds.org" <sls-rfm at mailman.ccsds.org>
Date: 08-04-21 20:45
Subject: RE: [Sls-rfm] [EXTERNAL] Re: CCSDS 401 structure naming
convention - proposed changes
Gian Paolo,
As much as I like details, I agree that the title need not
say what the data is. But it would be good to change the term “Command”
and “Telemetry”.
A big part of the intent of USLP is to make the “forward”
link and “return” link as similar as possible. But we may still want to
treat them with some differentiation. An Earth based receiver can be much
more complicated than a space based receiver. An Earth based transmitter
can have much more EIRP than a space based one. The section titles can be
simple but if possible, it would be nice if they informed the reader of
the differences. It may be as simple as words like “forward” and “return”
to indicate the initiator and the respondent, and let the section contents
cover the details.
Thanks,
Victor
From: Gian.Paolo.Calzolari at esa.int <Gian.Paolo.Calzolari at esa.int>
Sent: Thursday, April 8, 2021 2:14 PM
To: Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC]
<victor.j.sank at nasa.gov>
Cc: Enrico.Vassallo at esa.int; Jon Hamkins <Jon.Hamkins at jpl.caltech.edu>;
sls-rfm at mailman.ccsds.org
Subject: RE: [Sls-rfm] [EXTERNAL] Re: CCSDS 401 structure naming
convention - proposed changes
Victor,
my basic question with respect to a specific aspect of this
discussion is the following: does RFM WG really need to enter into the
detail of the type of carried data?
I mean, the input to a modulator is normally a stream of encoded bits. Why
would RFM need to know if those bits are from Housekeeping Telemetry or
from a scientific payload or from both?
The same for telecommand: does the modulator care about knowing the data
contain a command or a memory upload?
All this acknowledging that other points of the discussion may require
further discussion by the WG.
Ciao
Gian Paolo
From: "Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND
APPLICATIONS INC]" <victor.j.sank at nasa.gov>
To: "Jon Hamkins" <Jon.Hamkins at jpl.caltech.edu>, "
Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>, "
Enrico.Vassallo at esa.int" <Enrico.Vassallo at esa.int>
Cc: "sls-rfm at mailman.ccsds.org" <sls-rfm at mailman.ccsds.org>
Date: 08-04-21 20:04
Subject: RE: [Sls-rfm] [EXTERNAL] Re: CCSDS 401 structure naming
convention - proposed changes
Dear Enrico,
Before jumping into the section titles, I think we need to
agree on the meaning of the basic terms.
It seems to me that the term “command” is a limited term and
should be improved. Saying “uplink” is no longer good enough since we
must cover cross links. The term “Forward Link” has value because it can
cover many cases and to me implies the sender, no matter if it is an “up”
or “down” link. It does not cover what kind of data is being sent.
A remaining part of the terminology question is whether we
want to term to cover the type of data or information that is being
conveyed. The term “command” is very specific, it is a command and not
science data or a software load. But the term “telemetry” seems to be
less specific. I generally think of it as the return of housekeeping and
engineering information but I believe the term is used very general to
also include the returned (down linked) science or operational data. We
need to define what we mean by “telemetry”. My vote would be to use that
term “telemetry” for the housekeeping and engineering data on the return
link. On some projects we refer to the other returned data as the
“operational” data for a space weather satellite and “science” data for a
purely science satellite. I do not have a strong opinion, just stating
terms I have seen in use.
The section titles
Seems to me that section 2.2 Command and 2.4 Telemetry,
titles need to be improved.
I hesitate to propose the possible rewording until we decide on the
definition of the terms and if we what the title to convey of the kind of
data transferred. I think the title should contain some detail but at the
same time be general enough to allow for things we have not thought of, if
such thing is possible.
Regards,
Victor
From: SLS-RFM <sls-rfm-bounces at mailman.ccsds.org> On Behalf Of Jon Hamkins
via SLS-RFM
Sent: Thursday, April 8, 2021 11:20 AM
To: Gian.Paolo.Calzolari at esa.int; Enrico.Vassallo at esa.int
Cc: sls-rfm at mailman.ccsds.org
Subject: Re: [Sls-rfm] [EXTERNAL] Re: CCSDS 401 structure naming
convention - proposed changes
I think the note is a good idea to explain the more general nature of
these transmissions. If a change in terminology is made, I suggest
coordination with C&S and OPT Working Groups, because their blue books are
also using the terms telemetry and/or telecommand.
----Jon
Jon Hamkins
Chief Technologist, Communications, Tracking, and Radar Division
O 818-354-4764 (preferred) | M 626-658-6220 (does not work at home)
JPL | jpl.nasa.gov
On 4/8/2021 3:21 AM, Gian.Paolo.Calzolari at esa.int wrote:
Dear Enrico,
frankly speaking, the third possibility look to me the best one.
If strongly needed, a note could be added about using historical titles.
The general problem is that using new/different terms - as you correctly
remarks - 401.0-B may enter in conflict with different fora including
usage within CCSDS.
As an example, the notation forward/return (link) is mainly used to
generalise the diction specially when one side in not on Earth as done in
Proximity-1 Physical Layer book (see
https://public.ccsds.org/Pubs/211x1b4e1.pdf )
Ciao
Gian Paolo
From: Enrico.Vassallo at esa.int
To: sls-rfm at mailman.ccsds.org
Date: 08-04-21 10:05
Subject: [Sls-rfm] CCSDS 401 structure naming convention - proposed
changes
Sent by: "SLS-RFM" <sls-rfm-bounces at mailman.ccsds.org>
Dear RFM WG colleagues,
discussing high rate 22 GHz uplink recommendations, we noted that the
current structure naming convention may not be appropriate to cover
"generic" data transfer applications:
2.1 Earth-to-Space Radio Frequency 2.4
Telemetry
2.2 Telecommand 2.5
Radio Metric
2.3 Space-to-Earth Radio Frequency 2.6
Spacecraft
One possible solution would be to change the title of section 2.2 to
something like "Telecommand and forward data" and that of section 2.4 to
something like "Telemetry and return data".
This is to distinguish between telecommand and uplink data transfers (like
on-board software patch uploading, etc.) and between (HK) telemetry and
payload transmissions.
Note that already now recs 2.4.8 and 2.4.23 do not mention telemetry in
the title and deal with payload data. However, both recommendations have
pictures for symbol rate definition with captions indicating telemetry
symbol rate. I assume we will have the same in section 2.2.
One would need to check in detail all recommendations in 2.2 and 2.4,
which is a lot of work I think.
Another possibility is to change the section titles to "Telecommand
(including data transfer)" and "Telemetry (including data transfer)" so
that we can avoid checking current recommendations for consistency.
In addition, one could use as alternative to "data transfer" the "payload"
word although this is not generally utilized to indicate the same thing in
different fora.
The third possibility is to ignore this semantic problem and leave
everything unchanged.
Could I have your view by April 15 COB?
Regards, Enrico
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).
_______________________________________________
SLS-RFM mailing list
SLS-RFM at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-rfm
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).
_______________________________________________
SLS-RFM mailing list
SLS-RFM at mailman.ccsds.org
https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-rfm__;!!PvBDto6Hs4WbVuu7!f3bYBbEBsgWLEXHbQyqr6j0l8bZycehpQM0Ljy2_zpwWO2EY_xzn3CRU5kUrbGbUFxhy8Edz$
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).
_______________________________________________
SLS-RFM mailing list
SLS-RFM at mailman.ccsds.org
https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-rfm__;!!PvBDto6Hs4WbVuu7!eiarjuL0jNmmyodq4vv1n2IIj1NTIo-lHLA6vr4CfyteQzf1iN6ELUwSlncp0kJ3EAddZ3ko$
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).
_______________________________________________
SLS-RFM mailing list
SLS-RFM at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-rfm
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/sls-rfm/attachments/20210409/57b24312/attachment-0001.htm>
More information about the SLS-RFM
mailing list