Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xtce converter doesn't support LocationInContainerInBits #285

severn opened this issue Apr 18, 2016 · 2 comments

xtce converter doesn't support LocationInContainerInBits #285

severn opened this issue Apr 18, 2016 · 2 comments


Copy link

@severn severn commented Apr 18, 2016

(I removed the EnumerationAlarmLIst because this is not supported ---- do you really want me to make each unsupported xtce element an separate issue?).

Now for my 1 packet scenario I'm down to (I believe) the absolute addressing (LocationInContainerInBits) in container parameter entry.

Does the cosmos target DB support addressing its packet/container definition? (I'm poking around for documentation)

Copy link

@severn severn commented May 1, 2016

The answer is that if you use the ITEM keyword, the bit offset is required. The current xtce importer however calculates this for you based on the (implied) "previous entry" and ignores/complains about any offset set explicitly in xtce using LocationInContainerInBits.

One reason I want this supported -- that is fixed absolute addressing -- is that over time we've come to put the offset in all the entries for all our xtce files that are the product of a conversion. One reason is that certain missions that shall remain nameless like to use "union" style constructs & so can have overlapping in terms of address, mnemonic definitions.

This is especially true with mnemonics that consist of lots of contiguous 1 bit flags. These may for example be 16 1-bit flag mnemonics and then in conjunction with this a "union" will be defined with a single 16-bit "all flags" mnemonics encompassing this same set of flags.

So many of our real XTCE databases have the offset set explicitly for this reason -- and so it would be a big effort to try go through and pick out these "weird" union items... to strip them out so as to generate a relative addressed "packed" entry list... which could then processed by the importer tool.

(At one time we tried to mix addressing techniques -- only supplying the fixed addresses when needed, otherwise leaving it as relative style 'packed' addressing but this proved to be confusing so it was abandoned)

ryanatball added a commit that referenced this issue May 3, 2016
Copy link

@ryanatball ryanatball commented May 5, 2016

closed by pull request #291

@ryanatball ryanatball closed this May 5, 2016
@ryanatball ryanatball modified the milestone: v3.8.1 May 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.