CCSDS AOS Deframer

[Willmac16]

Related Issue(s)
Has Unit Tests (y/n)	y
Documentation Included (y/n)	n
Generative AI was used in this contribution (y/n)	y

---

Change Description

Add a CCSDS AOS SDL version 5 defamer that supports:

• Space Packet Protocol
• Encapsulation Packet Protocol
• FECF on or off
• 1 virtual channel--all the internal code should be ready for multiple just needs agreement on config & output port setup (i.e. vc per port array index)

Rationale

You need an AOS Deframer to rx AOS Frames from payloads/other craft.
AOS lets you do fixed frame width w/ variable packet size (including packets that span multiple frames)

Testing/Review Recommendations

Take a look at the processing I'm doing on SPP & EPP packets and what I'm emitting in the context for them. I could imagine a later rev of this component sharing w/ SPP defamer more logic/doing its job for it.

Other facet on the SPP & EPP processing is how light my validation is. I'm only checking that they contain the right PVN & grabbing size + idle. If we moved the full SPP parsing into this/called into a lib then you could maybe avoid throwing away packets by ID-ing a problem earlier (although dropping a frame upon packet issues is probably the only safe thing to do).

A double check on my read of the EPP spec would be beneficial since I caught a few bugs that lingered all the way into testing.

Future Work

I am likely done w/ AOS for near term; however, future work could be:

• Porting downlink stack to AOS
• Using AOS Framer to bootstrap USLP
• Making a proper EPP Framer & Deframer
• Consolidating logic into a lib btw AOS, SPP, & EPP deframers
• Writing an AOS Frame Detector if using AOS over a byte stream like tcp vs a datagram protocol like UDP

AI Usage (see policy)

• Claude Code for Web did the first pass
• The Claude Code GitHub extension addressed feedback on 3-4 commits
• Over the past couple days, while I worked in VSCode I would use ChatGPT Codex & Claude Code CLI for minor code movement/event creation and test tweaks. I've reviewed (and quite often heavily refactored) all of the flight code to match my stylistic and structural preferences

Overall, I'm not convinced the first 2 steps really provided that much of a speedup since much of the EPP structure was completely wrong, and the approach to spanning packets had significant code duplication. Maybe a minor psychological speedup simply because I had code to review to bootstrap rather than a blank slate.

The minor test writing & event creation usage felt like a speedup, but better editor skills/snippets might be able to handily beat that.

[thomas-bc]

@Willmac16 Svc_Ccsds_AosDeframer_ut_exe is failing, are you able to take a look?

[Willmac16]

Yeah I’ll try to resolve tmrwSent from my iPhoneOn Apr 30, 2026, at 20:30, Thomas Boyer-Chammard ***@***.***> wrote:thomas-bc left a comment (nasa/fprime#4779) @Willmac16 Svc_Ccsds_AosDeframer_ut_exe is failing, are you able to take a look? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[Willmac16]

Looks like the macOS/regular linux fails are bc I changed that Only Idle Data abandon behavior but failed to correct the UT. Patch going up shortly for that

And then RHEL8 casting errors, my old friend.

[Willmac16]

Can you fight the RHEL8 error for me? Unless I can quickly run the tests against it, it's very hard to iterate and converge on what exactly its mad about

[thomas-bc]

Here is what Opus 4.7 helped me find:

The error isn't really about the shift operand or the inner static_cast(...) — it's the compound assignment itself. U16 |= U16 expands to U16 = U16 | U16, and per C++ integer-promotion rules the bitwise OR of two unsigned short operands is computed as int, so the implicit narrowing on the assignment back (int → U16) is what -Wconversion flags. GCC unhelpfully reports the location at the closing ) of the inner static_cast, which makes it look like the cast is the problem when it's actually one level up.

So the way to appease GCC (not specific to RHEL8!! it just looks like the rest of our CI is using clang? EDIT: No, RHEL CI is using an old version of GCC and that's the issue - the Ubuntu CI is using a more recent version of GCC that doesn't have the issue) is to not do the U16 |= U16, and do everything in one operation. Or expand into scid = static_cast<U16>(scId | [expr]) but it became even less readable imo. I'm happy with that. Thoughts?

[Willmac16]

Whatever makes it pass works w/ me! Do we really use clang for Ubuntu?Sent from my iPhoneOn May 6, 2026, at 17:29, Thomas Boyer-Chammard ***@***.***> wrote:thomas-bc left a comment (nasa/fprime#4779) Here is what Opus 4.7 helped me find: The error isn't really about the shift operand or the inner static_cast(...) — it's the compound assignment itself. U16 |= U16 expands to U16 = U16 | U16, and per C++ integer-promotion rules the bitwise OR of two unsigned short operands is computed as int, so the implicit narrowing on the assignment back (int → U16) is what -Wconversion flags. GCC unhelpfully reports the location at the closing ) of the inner static_cast, which makes it look like the cast is the problem when it's actually one level up. So the way to appease GCC (not specific to RHEL8!! it just looks like the rest of our CI is using clang?) is to not do the U16 |= U16, and do everything in one operation. I'm happy with that. Thoughts? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[thomas-bc]

@Willmac16 ah you're right. Then I think it may be that RHEL is using an older version of GCC (GNU 8.5.0 per CI logs) that has this quirk, where ubuntu's version (GNU 11.4.0 per CI logs) is smarter about it.

[thomas-bc]

@Willmac16 ok I think we're almost ready to merge this. I opened a PR on your branch for a few security-related items: Willmac16#8 - let me know.

These are the kind of issues that the community has been reporting to us in our comms stack, and we've been spending a lot of time fixing. So I figured it'd be worth fixing them from the get-go here.

Once those changes are accepted into your branch I am ready to merge this.

[Willmac16]

Totally agree with fixing things before pre-merge; thanks for taking care of them!

[Willmac16]

I think we might need to abandon any spanning packets upon an out of bounds first header pointer. I’ll double check if that’s already happening, but I think you can’t assume that any state should continue through an invalid frame. Otherwise we’ll get some Franken-packetSent from my iPhoneOn May 6, 2026, at 20:06, Thomas Boyer-Chammard ***@***.***> wrote:thomas-bc left a comment (nasa/fprime#4779) @Willmac16 ok I think we're almost ready to merge this. I opened a PR on your branch for a few security-related items: Willmac16#8 - let me know. These are the kind of issues that the community has been reporting to us in our comms stack, and we've been spending a lot of time fixing. So I figured it'd be worth fixing them from the get-go here. Once those changes are accepted into your branch I am ready to merge this. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[Willmac16]

Is this ready to merge? finally