Skip to content

Commit f99de8b

Browse files
nikhil-pixxelnikhil-pixxel
committed
test
1 parent 7cc948a commit f99de8b

9 files changed

Lines changed: 762 additions & 403 deletions

File tree

‎examples/pus/src/main/yamcs/etc/yamcs.yaml‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ services:
77
instances:
88
- pus
99

10-
dataDir: /storage/yamcs-data
10+
dataDir: yamcs-data
1111

1212
#set the serverId if you want something else than hostname to be used in system parameters generated by yamcs
1313
#serverId: yamcs1

‎pus_analysis/pus11.md‎

Lines changed: 101 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -760,3 +760,104 @@ repeat N:
760760
| #4 Groups TC[11,22–26]+TM[11,27] | Medium | MDB: MCS; Java: demo/test only | Partial — MDB ✅, Java (sim) ❌ | Low |
761761
| #5 TC[11,20/21] N>1 | Low | Demo/test simulator only | ❌ Java sim only | Trivial |
762762
| #6 TC[11,6/8/14] filter_type | Low | MCS (operator interface) | ✅ Yes | Minor |
763+
764+
---
765+
766+
## D. Native MCS Implementation — Java vs XTCE-only
767+
768+
### Verdict: XTCE-only (with one built-in exception)
769+
770+
ST[11] is **XTCE-only on the ground side**. No `Pus11Service.java` exists in `yamcs-core` and none is required for normal MCS operation. This is the opposite of ST[05], where `PusEventDecoder` is mandatory because TM[5,1–4] must be promoted to YAMCS native events — a conversion that cannot be expressed in XTCE.
771+
772+
For ST[11]:
773+
- All **TC sends** are encoded as XTCE MetaCommands + `PusCommandPostprocessor`
774+
- All **TM receives** (TM[11,13], TM[11,19], TM[11,27]) are ordinary XTCE parameter containers — no native event emission needed
775+
776+
The one "Java" piece is `PusCommandPostprocessor.buildScheduledTc()` in `yamcs-core/src/main/java/org/yamcs/pus/PusCommandPostprocessor.java` (lines 128–190), but that code already exists and requires no new implementation. It handles the `pus11ScheduleAt` command extra transparently.
777+
778+
---
779+
780+
### Per-message table
781+
782+
| Message | MCS Role | XTCE Sufficient? | Java Required? | Notes |
783+
|---------|----------|-----------------|----------------|-------|
784+
| TC[11,1] | Send | **Yes** | No | `ENABLE_SCHEDULER`, no args |
785+
| TC[11,2] | Send | **Yes** | No | `DISABLE_SCHEDULER`, no args |
786+
| TC[11,3] | Send | **Yes** | No | `RESET_SCHEDULER`, no args |
787+
| TC[11,4] | Send | **Partial** | No (already done) | Direct MDB limited to fixed-size TCs (Gap #1); production path uses `pus11ScheduleAt` extra handled by `PusCommandPostprocessor` |
788+
| TC[11,5] | Send | **Yes** | No | Array of `{source_id, apid, seqcount}` |
789+
| TC[11,6] | Send | **Yes** | No | filter_type hardcoded to 0x01 (Gap #6) |
790+
| TC[11,7] | Send | **Yes** (with fix) | No | Missing `time_offset_ms` arg (Gap #2) |
791+
| TC[11,8] | Send | **Yes** (with fix) | No | Same as TC[11,7] (Gap #2) |
792+
| TC[11,12] | Send | **Yes** | No | Array of request IDs |
793+
| TC[11,14] | Send | **Yes** | No | Same as TC[11,6] |
794+
| TC[11,15] | Send | **Yes** (with fix) | No | Wrong args currently (Gap #3) |
795+
| TC[11,16] | Send | **Yes** | No | No args |
796+
| TC[11,17] | Send | **Yes** | No | No args |
797+
| TC[11,18] | Send | **Yes** | No | No args |
798+
| TC[11,20] | Send | **Yes** | No | Array of subschedule IDs |
799+
| TC[11,21] | Send | **Yes** | No | Same as TC[11,20] |
800+
| TC[11,22–25] | Send | **Yes** | No | Not in MDB yet (Gap #4), but fully expressible in XTCE |
801+
| TC[11,26] | Send | **Yes** | No | Not in MDB yet (Gap #4) |
802+
| TM[11,13] | Receive | **Yes** | No | XTCE container with dynamic array of summary entries |
803+
| TM[11,19] | Receive | **Yes** | No | XTCE container with `{id, status}` array |
804+
| TM[11,27] | Receive | **Yes** | No | Not in MDB yet (Gap #4), but fully expressible in XTCE |
805+
806+
---
807+
808+
### `pus11ScheduleAt` command extra (already implemented)
809+
810+
`org.yamcs.pus.PusCommandPostprocessor` registers the `pus11ScheduleAt` command option at class load time:
811+
812+
```java
813+
public static final CommandOption OPTION_SCHEDULE_TIME = new CommandOption(
814+
"pus11ScheduleAt", "Schedule Time", CommandOptionType.TIMESTAMP);
815+
```
816+
817+
When a TC is issued with this attribute set, `buildScheduledTc()` wraps the encoded TC binary inside a TC[11,4] packet:
818+
- Writes `subschedule_id=1`, `N=1`
819+
- Encodes the CUC release time
820+
- Appends the original TC binary verbatim
821+
- Fills CCSDS sequence count and optional CRC
822+
823+
This means **operators can schedule any existing TC from YAMCS Web** by setting the Schedule Time option. No MDB change or new Java is needed for this path.
824+
825+
Config in `yamcs.*.yaml` (tc_realtime data link):
826+
```yaml
827+
commandPostprocessorClassName: org.yamcs.pus.PusCommandPostprocessor
828+
commandPostprocessorArgs:
829+
errorDetection:
830+
type: CRC-16-CCIIT
831+
timeEncoding:
832+
implicitPfield: false
833+
pfield: 0x2f
834+
pus11Crc: true # optional, default true — add CRC to TC[11,4]
835+
pus11Apid: 1 # optional — override APID on the TC[11,4] wrapper
836+
tcoService: tco0
837+
```
838+
839+
---
840+
841+
### Contrast with ST[05]
842+
843+
| | ST[05] | ST[11] |
844+
|--|--------|--------|
845+
| Native Java needed? | **Yes** — `PusEventDecoder` | **No** |
846+
| Why Java for TM? | TM[5,1–4] must be promoted to YAMCS native events (events stream) — no XTCE mechanism exists for this | TM[11,13/19/27] are parameter containers — decoded by XTCE directly |
847+
| Existing Java in yamcs-core | `Pus5Service`, `PusEventDecoder` | `PusCommandPostprocessor.buildScheduledTc()` (already present) |
848+
| XTCE for TC? | Yes (TC[5,5/6/7]) | Yes (all subtypes) |
849+
| XTCE for TM? | Partial — XTCE decodes params, but Java needed for event emission | Full — XTCE decodes all TM packets |
850+
851+
---
852+
853+
### When would a `Pus11Service` in yamcs-core be needed?
854+
855+
Only if you run the on-board scheduler **inside the YAMCS process** (HITL or a YAMCS-as-spacecraft scenario). In that case:
856+
857+
1. Create `yamcs-core/src/main/java/org/yamcs/pus/Pus11Service.java` extending `PusTcHandler`
858+
2. Register under `PusCommandReleaser` with `serviceType: 11`
859+
3. Implement `handleTc(PreparedCommand)` dispatching to subtypes 1–21 (groups 22–26 optional)
860+
861+
This mirrors `Pus11Service.java` in `simulator/` exactly, but uses `emitTm(serviceType, subtype, appData)` from `PusCommandReleaser` instead of `pusSimulator.transmitRealtimeTM(pkt)`.
862+
863+
For a ground-only MCS, no such service is needed.

‎pus_analysis/pus14.md‎

Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1068,6 +1068,58 @@ All TC/TM packet structures for ST[14] are fully expressible in XTCE:
10681068

10691069
---
10701070

1071+
## d) Native MCS Implementation — Java vs XTCE-only
1072+
1073+
### Verdict: XTCE-only
1074+
1075+
ST[14] is **XTCE-only on the ground side**. No Java exists or is needed in `yamcs-core` for ST[14]. This is stated in §a):
1076+
1077+
> *YAMCS/MCS implementation = XTCE only (`pus14.xml`). No Java changes to `yamcs-core` are needed for ST[14].*
1078+
1079+
All TC sends are encoded as XTCE MetaCommands. All TM receives (TM[14,4], TM[14,8], TM[14,12]) are XTCE parameter containers. The on-board forwarding control logic (APFCC/HK FCC/Diag FCC management, `shouldForward()` gate) lives **entirely in the simulator** — it emulates satellite-side behavior. YAMCS MCS only sends configuration TCs and decodes FCC dump TM reports — both purely via XTCE.
1080+
1081+
---
1082+
1083+
### Per-message table (MCS ground side only)
1084+
1085+
| Message | MCS Role | XTCE Sufficient? | Java Required? | Notes |
1086+
|---------|----------|-----------------|----------------|-------|
1087+
| TC[14,1] | Send | **Yes** | No | Single MetaCommand with N1/N2/N3 nested arrays; N2=0/N3=0 encode "add all" |
1088+
| TC[14,2] | Send | **Yes** | No | 2 variants: delete-entries (reuses TC[14,1] types) + empty-APFCC (no args) |
1089+
| TC[14,3] | Send | **Yes** | No | No args — identical to TC[11,17] pattern |
1090+
| TM[14,4] | Receive | **Yes** | No | 3-level nested `ContainerRefEntry` repeats; `CURRENT_ENTRY_WITHIN_PACKET` picks most-recent `N_subtypes` per iteration |
1091+
| TC[14,5] | Send | **Yes** | No | Single MetaCommand, N1/N_structs 2-level nested; N_structs=0 = "add all" |
1092+
| TC[14,6] | Send | **Yes** | No | 2 variants: delete-entries + empty-HK-FCC (no args) |
1093+
| TC[14,7] | Send | **Yes** | No | No args |
1094+
| TM[14,8] | Receive | **Yes** | No | Flat 2-level dynamic array; fully XTCE-expressible |
1095+
| TC[14,9] | Send | **Yes** | No | Mirror of TC[14,5] for diagnostic FCC |
1096+
| TC[14,10] | Send | **Yes** | No | Mirror of TC[14,6] for diagnostic FCC |
1097+
| TC[14,11] | Send | **Yes** | No | No args; mirror of TC[14,7] |
1098+
| TM[14,12] | Receive | **Yes** | No | Mirror of TM[14,8] for diagnostic FCC |
1099+
1100+
---
1101+
1102+
### Contrast with ST[05] and ST[11]
1103+
1104+
| | ST[05] | ST[11] | ST[14] |
1105+
|--|--------|--------|--------|
1106+
| Native Java needed in yamcs-core? | **Yes** — `PusEventDecoder` | **No** | **No** |
1107+
| Why Java for TM? | TM[5,1–4] must be promoted to YAMCS native events (events stream) — no XTCE mechanism | N/A | N/A |
1108+
| Existing yamcs-core Java | `Pus5Service`, `PusEventDecoder` | `PusCommandPostprocessor.buildScheduledTc()` (already present) | None needed |
1109+
| XTCE for TC? | Yes | Yes | Yes |
1110+
| XTCE for TM? | Partial (params decoded, events need Java) | Full | Full |
1111+
| On-board Java (simulator only) | `Pus5Service` in simulator | `Pus11Service` in simulator | `Pus14Service` in simulator (to be created) |
1112+
1113+
---
1114+
1115+
### When would yamcs-core Java be needed?
1116+
1117+
Only if YAMCS itself acted as a forwarding filter — i.e., if YAMCS should gate TM packets before archiving them based on an APFCC. That is explicitly **not** the design here: the forwarding control table lives on-board (or in the simulator), and YAMCS MCS archives whatever packets the satellite chooses to downlink.
1118+
1119+
If a future requirement added MCS-side filtering (e.g., suppressing certain TM packets before they reach the parameter archive), a `PusTmFilter` service in `yamcs-core` would be needed. That is not a ST[14] requirement — it would be a YAMCS architectural extension.
1120+
1121+
---
1122+
10711123
## Implementation Files (when building)
10721124

10731125
| Layer | File | Action |

0 commit comments

Comments
 (0)