You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The MIB, or Management Information Base, contains CFDP related communication parameters - most importantly entity IDs. See CCSDS 727.0-B-5 (the Blue Book) section 8 for the full list. Each CFDP entity has one local configuration (table 8-1) and a collection of remote configurations (table 8-2), one for each known entity that the local entity will communicate with. Since they're shared information between various locations (here the C3 and ground), oresat-configs is a good location to keep all of them.
In cfdpy-py these are implemented with LocalEntityCfg and RemoteEntityCfg which are simple dataclasses. There's ample examples of converting yaml -> dataclass, but yaml parsing is very slow so it'd be a bit tragic to add another file to the pile. We could just write the classes directly in python - that'd be the fastest with no external parsing required, but other languages couldn't then parse them. I think yamcs wants to use this? Which is Java? I don't think a CSV would be a good fit, there's too many fields to be reasonably readable. TOML could work but that'd be introducing yet another markup language.
Also the local entity default fault handlers and remote entity opportunities should be left out as they're likely to be project specific code instead of data.
The text was updated successfully, but these errors were encountered:
The MIB, or Management Information Base, contains CFDP related communication parameters - most importantly entity IDs. See CCSDS 727.0-B-5 (the Blue Book) section 8 for the full list. Each CFDP entity has one local configuration (table 8-1) and a collection of remote configurations (table 8-2), one for each known entity that the local entity will communicate with. Since they're shared information between various locations (here the C3 and ground), oresat-configs is a good location to keep all of them.
In cfdpy-py these are implemented with
LocalEntityCfg
andRemoteEntityCfg
which are simpledataclass
es. There's ample examples of converting yaml -> dataclass, but yaml parsing is very slow so it'd be a bit tragic to add another file to the pile. We could just write the classes directly in python - that'd be the fastest with no external parsing required, but other languages couldn't then parse them. I think yamcs wants to use this? Which is Java? I don't think a CSV would be a good fit, there's too many fields to be reasonably readable. TOML could work but that'd be introducing yet another markup language.Also the local entity default fault handlers and remote entity opportunities should be left out as they're likely to be project specific code instead of data.
The text was updated successfully, but these errors were encountered: