[Sls-rfm] [EXTERNAL] CCSDS RFM WG AI_20-01 (PN register convention)

Fri Jun 26 13:43:20 UTC 2020

Victor,

you are saying we can leave 415-B and G as they are and just remove the 
polynomials from REC 2.5.7B when it ends up in 401-B?

Regards, Enrico 

From:   "Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS 
INC]" <victor.j.sank at nasa.gov>
To:     "Enrico.Vassallo at esa.int" <Enrico.Vassallo at esa.int>
Cc:     "Kazz, Greg J (JPL-312B)[Jet Propulsion Laboratory]" 
<greg.j.kazz at jpl.nasa.gov>, "Border, James S (JPL-335D)[Jet Propulsion 
Laboratory]" <james.s.border at jpl.nasa.gov>, "sls-rfm at mailman.ccsds.org" 
<sls-rfm at mailman.ccsds.org>, "Rodriguez, Shannon (GSFC-5670)" 
<shannon.rodriguez-1 at nasa.gov>
Date:   26/06/20 15:01
Subject:        RE: [EXTERNAL] [Sls-rfm] CCSDS RFM WG AI_20-01 (PN 
register convention)

Enrico,
               Yes, the 414.0-G-2 and 414.1-B-1 documents I mentioned are 
not ones that is affected by the proposal in SLS-CS_20-03 in the first 
place because they do not have polynomials, it just has the patterns of 
the components..  This is exactly the point we are trying to make. Stating 
the pattern or showing a diagram of the generator shift register is 
unique, the polynomial is not.  The 414 books are the only ones we noticed 
that have no ambiguity since they do not have polynomials.  Hence our 
suggestion to not state polynomials in future CCSDS books, unless some 
standard is decided upon. 
Victor

From: Enrico.Vassallo at esa.int <Enrico.Vassallo at esa.int> 
Sent: Friday, June 26, 2020 8:09 AM
To: Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] 
<victor.j.sank at nasa.gov>
Cc: Kazz, Greg J (JPL-312B)[Jet Propulsion Laboratory] 
<greg.j.kazz at jpl.nasa.gov>; Border, James S (JPL-335D)[Jet Propulsion 
Laboratory] <james.s.border at jpl.nasa.gov>; sls-rfm at mailman.ccsds.org
Subject: RE: [EXTERNAL] [Sls-rfm] CCSDS RFM WG AI_20-01 (PN register 
convention)

Victor, 

I must say that I do not understand your proposal. The document you 
mention is not one that is affected by the proposal in SLS-CS_20-03 in the 
first place. 

Anyway, I think we should proceed with agency review of REC 2.5.7B 
assuming I do not get other comments today. I would use the version just 
sent out by Jim, having just encapsulated the latest inclusion in a note 
since this is not normative as suggested by our beloved AD. 

The PN action is due next September, so we have time to discuss. 

Cheers, Enrico 

From:        "Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND 
APPLICATIONS INC]" <victor.j.sank at nasa.gov> 
To:        "Enrico.Vassallo at esa.int" <Enrico.Vassallo at esa.int>, "
sls-rfm at mailman.ccsds.org" <sls-rfm at mailman.ccsds.org>, "Border, James S 
(JPL-335D)[Jet Propulsion Laboratory]" <james.s.border at jpl.nasa.gov> 
Cc:        "Kazz, Greg J (JPL-312B)[Jet Propulsion Laboratory]" <
greg.j.kazz at jpl.nasa.gov> 
Date:        25/06/20 21:14 
Subject:        RE: [EXTERNAL] [Sls-rfm] CCSDS RFM WG AI_20-01 (PN 
register convention) 

Enrico,
               I have a very simple solution to the issue of PN generator 
diagrams and the associated polynomial.  Do not state the polynomial in 
CCSDS documents. 
               In our CCSDS books we always show the generator diagram 
which is (unique) necessary and sufficient. 
We can avoid the editing issue by not changing the existing books but 
going forward, let’s not publish the ambiguous polynomial.  At least one 
of our books shows the generator diagram and never states a polynomial 
(414.1-B).

The generator shift register diagram (Fibonacci, Galois, Gold) produces a 
unique pattern and in a specific direction of flow.  The polynomial is 
ambiguous.  For maximal patterns there are two polynomials that produce 
patterns with the same statistic but when represented as a bit pattern, 
the bit flow is in opposite directions.  When doing abstract algebra, this 
may not matter.  When used in communications, it does matter.  For example 
a communications de-randomizer must flow in the same direction at the 
randomizer.   In the case where a pattern is truncated, using the same 
starting point, the statistics will be different depending on the flow 
direction. 
Thanks,
Victor

From: SLS-RFM <sls-rfm-bounces at mailman.ccsds.org> On Behalf Of 
Enrico.Vassallo at esa.int
Sent: Monday, June 22, 2020 5:32 AM
To: sls-rfm at mailman.ccsds.org; Border, James S (JPL-335D)[Jet Propulsion 
Laboratory] <james.s.border at jpl.nasa.gov>
Cc: Kazz, Greg J (JPL-312B)[Jet Propulsion Laboratory] <
greg.j.kazz at jpl.nasa.gov>
Subject: [EXTERNAL] [Sls-rfm] CCSDS RFM WG AI_20-01 (PN register 
convention)

Dear All, 

please find my response as both ESA representative in RFM WG and as RFM WG 
chair to the action item: 

AI_20-01        Report about the PN register proposal in CS_20-03, the 
possible need to have a similar standard representation and, in case, the 
preferred way forward 

Input paper CS_20-03 recommends changes to the following RFM WG books: 

1) 415.1-B-1, dated 2011 

2) 415.1-G-1, dated 2013 

3) 401.1-B REC 2.5.7B-white 

Document CS_20-03 proposes to adopt the Matlab convention. 
Main differences between what's in documents 1-3 and the proposal in 
CS_20-03 is the fact that in the pictures the output register is numbered 
N in 1-3 as opposed to 0 in the proposal; additionally, the first register 
is numbered 1 (zero is not used in 1-3). 

Documents 1-2-3 are consistent. 
Document 2 (green book) provides in page 3-3 a detailed explanation of the 
convention used, addresses different conventions in literature, and links 
the drawing of the picture with resulting equations and polynomials. This 
info is in sections 3.4 to 3.8. 
Document 1 (blue book) provides some explanation of the convention used in 
section 1.6.2. 
Document 3 has two pictures in Annex A with no explanation while the 
polynomials are in the main body of the recommendation. 

Documents 1-2 were mainly NASA's (GFSC) inputs aimed at extending the SNIP 
agreement (latest version from 1998) between ESA, NASA and NASDA (now 
JAXA) for which the latest version dates November 1998 to encompass more 
CCSDS agencies. 

The change request in CS_20-03 would entail editing the following number 
of pictures: 5 (doc 1) + 10 (doc 2) + 2 doc (3) = 17 in addition to 
adjusting the related text. 

Given that documents 1 and 2 have been used for almost a decade with no 
report of implementation mistakes by ESA equipment developers, and the 
changes in CS_20-03 would result in full disagreement with the SNIP 
document, it is proposed NOT to adopt the Matlab convention for the RFM WG 
books. However, concerning the draft DDOR recommendation 2.5.7B under 
development, some explanation could be added as done in 1 (or even in 2.) 

It is possible that other WGs of the SLS area may prefer a different 
approach for their books but as long as the recommendations of the same WG 
are consistent, I do not see this as an issue. 

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).
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).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-rfm/attachments/20200626/fbe2a07f/attachment-0001.htm>