[Sls-rfm] Proposed editorial changes to telecommand recommendations in 401

Enrico.Vassallo at esa.int Enrico.Vassallo at esa.int
Thu Dec 13 08:43:54 UTC 2018


Dear Dennis,

recognizing that in the 401 glossary we have 

sps or s/s      Symbols Per Second

what about using coded (M) (k) sps instead of coded (M) (k) sym/s? Other 
views are for using coded (M) (k) symbol/s.

Of course we will need to change the glossary once also the telemetry 
recommendations are aligned and s/s does not exist anymore.

Regards, Enrico

 


From:   Enrico Vassallo/esoc/ESA
To:     "Lee, Dennis K (332G)" <Dennis.K.Lee at jpl.nasa.gov>
Cc:     "Andres, Brent (GSFC-567.0)[AS and D, Inc.]" 
<brent.r.andres at nasa.gov>, "Charlson, Deane R. (GSFC-5670)" 
<deane.r.charlson at nasa.gov>, "Kazz, Greg J (312B)" 
<Greg.J.Kazz at jpl.nasa.gov>, "GARON, Howard M (GSFC-567.0)[MUNIZ] 
(howard.garon at nasa.gov)" <howard.garon at nasa.gov>, "Hamkins, Jon (3320)" 
<Jon.Hamkins at jpl.nasa.gov>, "Andrews, Kenneth S (332B)" 
<Kenneth.S.Andrews at jpl.nasa.gov>, "Powers, Michael K. (GSFC-5670)" 
<michael.k.powers at nasa.gov>, "Rodriguez, Shannon (GSFC-5670)" 
<shannon.rodriguez-1 at nasa.gov>, "'victor.j.sank at nasa.gov'" 
<victor.j.sank at nasa.gov>, "'wai.h.fong at nasa.gov'" <wai.h.fong at nasa.gov>, 
"HUANG, WEI-CHUNG. (GSFC-5670) (weichung.huang at nasa.gov)" 
<weichung.huang at nasa.gov>, sls-rfm at mailman.ccsds.org
Date:   10/12/2018 09:34
Subject:        RE: [Sls-rfm] Proposed editorial changes to telecommand 
recommendations in 401


Dear Dennis,

I agree with NASA's proposal. Gian Paolo had even suggested adding the 
picture you are quoting so ESA and NASA are in line on this one.

I will take care if this and I kindly ask you to make a proposal for the 
rest of the Blue Book, in time for the next meeting.

Regards, Enrico




From:   "Lee, Dennis K (332G)" <Dennis.K.Lee at jpl.nasa.gov>
To:     "Enrico.Vassallo at esa.int" <Enrico.Vassallo at esa.int>
Cc:     "'victor.j.sank at nasa.gov'" <victor.j.sank at nasa.gov>, "Hamkins, Jon 
(3320)" <Jon.Hamkins at jpl.nasa.gov>, "Andrews, Kenneth S (332B)" 
<Kenneth.S.Andrews at jpl.nasa.gov>, "Kazz, Greg J (312B)" 
<Greg.J.Kazz at jpl.nasa.gov>, "GARON, Howard M (GSFC-567.0)[MUNIZ] 
(howard.garon at nasa.gov)" <howard.garon at nasa.gov>, "'wai.h.fong at nasa.gov'" 
<wai.h.fong at nasa.gov>, "Rodriguez, Shannon (GSFC-5670)" 
<shannon.rodriguez-1 at nasa.gov>, "Andres, Brent (GSFC-567.0)[AS and D, 
Inc.]" <brent.r.andres at nasa.gov>, "HUANG, WEI-CHUNG. (GSFC-5670) 
(weichung.huang at nasa.gov)" <weichung.huang at nasa.gov>, "Powers, Michael K. 
(GSFC-5670)" <michael.k.powers at nasa.gov>, "Charlson, Deane R. (GSFC-5670)" 
<deane.r.charlson at nasa.gov>
Date:   10/12/2018 08:25
Subject:        RE: [Sls-rfm] Proposed editorial changes to telecommand 
recommendations in 401



Enrico,
 
There were comments from a number of NASA reviewers that “s/s” is a 
confusing notation that should not be used.  The abbreviation “s” is used 
to mean two different things in the numerator and denominator. 
Furthermore, “s” as an abbreviation for symbol is ambiguous since it 
doesn’t differentiate between code symbols and channel symbols. 
 
The NASA proposal is to replace “s/s” with “coded sym/s”, and “ks/s” with 
“coded ksym/s”.  This would be aligned with the terminology in 211.2-B-2 
(see Figure 1-2 attached), and help differentiate from the common use of 
“symbol” to mean “baud” in the literature and in industry.  Ultimately, we 
would like to see the rest of the 401 Blue Book aligned this way as well, 
with references to "symbols" to be clarified as either "coded symbols" or 
"channel symbols", "s/s" to be replaced by "coded sym/s" or "channel 
sym/s" as appropriate, and "R_s" to be clarified as either "R_cs" or 
"R_chs". 
 
Thanks,
Denis
 
From: SLS-RFM <sls-rfm-bounces at mailman.ccsds.org> On Behalf Of 
Enrico.Vassallo at esa.int
Sent: Wednesday, December 5, 2018 3:12 AM
To: sls-rfm at mailman.ccsds.org
Subject: [Sls-rfm] Proposed editorial changes to telecommand 
recommendations in 401
 
Dear All, 

as you know all our missions have used or are currently using the standard 
telecommand BCH (63,56) encoding. For all these cases, the bandwidth 
expansion is 1.125 which basically means bit rate equals symbol rate. For 
this and other historical reasons, all 401 recommendations for telecommand 
only talk about bit rates assuming that they are actually symbol rates. 
With the first missions considering LDPC 1/2 for telecommand, there is a 
need to remove the confusion by changing bit rates into symbol rates while 
keeping the same limits as in present recommendations. I think this is 
just a purely editorial issue. 

Please let me know if you agree with my proposal and if anything is 
missing in the attachments. If I do not hear from you by December 12, I 
assume your concurrence and will submit the attached document (or its 
amended version in case of suggestions) to the CCSDS editor. 

Best 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).[attachment "Screen Shot 2018-12-05 
at 3.20.40 PM.png" deleted by Enrico Vassallo/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/sls-rfm/attachments/20181213/aa364a96/attachment.html>


More information about the SLS-RFM mailing list