[CESG] General comment and question on the new TM Sync and Coding blue book (131-B-6)

[Clemens Heese]

Dear James,

I think people will always be stating CCSDS compliance blindly, what matters IMHO is the statement to which subset of a CCSDS standard they are compliant.
Tomaso is right, the ICS statement is a better way to state specific compliance.
Let us discuss today, if we want to also emphasize the ICS statement update in blue book updates to address this issue.

Regards,

Clemens

From: CESG <cesg-bounces at mailman.ccsds.org> on behalf of Tomaso de Cola - SIS AD via CESG <cesg at mailman.ccsds.org>
Date: Wednesday, 4. March 2026 at 12:07
To: james.p.lux at jpl.nasa.gov <james.p.lux at jpl.nasa.gov>, cesg at mailman.ccsds.org <cesg at mailman.ccsds.org>
Subject: Re: [CESG] General comment and question on the new TM Sync and Coding blue book (131-B-6)

>From a CCSDS perspective, once this B-6 version will be published, the B-5 will be silverised and get the identified B-5-S and such to be considered historical or obsoleted. In light of this, in my opinion, an implementation shall be conformant to the B-6 version. I’m also scared of the “CCSDS compliant coding” statement because in this very specific case it might mean that a spacecraft implementation follow B-5 (i.e. no pseudo-randomizer) and a ground station follow B-6 (i.e. pseudo-randomiser, with the receiver “trying” to de-randomize the incoming TFs).

What in my opinion is also tricky is that these old books that are periodically revised are not expected to implement an ICS annex, which somehow can already guide implementers as to what shall be supported for a CCSDS-interoperable implementation.

My 0.02 cents,

Tomaso

From: CESG <cesg-bounces at mailman.ccsds.org> On Behalf Of Lux, Jim (US 430E) via CESG
Sent: Tuesday, March 3, 2026 9:21 PM
To: CESG All <cesg at mailman.ccsds.org>
Subject: [CESG] General comment and question on the new TM Sync and Coding blue book (131-B-6)

I approved, but I have a question..
One thing that got changed is that now a randomizer is required (it’s a shall).  Does this make an existing implementation without a randomizer now “non-conformant” by definition?
Let’s say someone has a “product” (mission, software, a box, whatever) that advertises “Coding is implemented in conformance with CCSDS 131.0-B-5” … Are consumers of the product smart enough to go look and see if there’s a new issue (-6)?  What if they say “CCSDS compliant coding” with no specification number or issue. This is super common, in my experience, and experience says “better go check the details”.  But with the recent influx of new people doing spaceflight stuff, what’s the implications of that – (Other than hiring me or someone like me with experience as a consultant to help them not step into the tarpit).

[JPL logo]
James Lux
Data Standards Program Manager
4200 Telecom Programs and Oversight
JPL
4800 Oak Grove Drive
Pasadena, CA 91109
M: 818.395.2714
O: 818.354.2075
jimlux at jpl.nasa.gov<mailto:jimlux at jpl.nasa.gov>



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/cesg/attachments/20260304/1bed8482/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2081 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20260304/1bed8482/attachment.png>