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

Thu Jun 25 19:14:34 UTC 2020

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<mailto:dpo at esa.int>).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-rfm/attachments/20200625/265553b0/attachment.htm>