Make the sgp4 example more noisy
BaldBeacon opened this issue · 3 comments
Although this seems like a strange issue, it's not very obvious to a user whether or not the example sgp4 app works. It would be a nice addition to sgp4 to add some sort of periodic event message to show that the app has initialized and the main loop is executing.
Edit: The simple app could benefit from this as well.
Looking at this suggestion, I'm not sure the sample app needs an event. It will already issue an event upon receipt of a command, so it seems trivial to trigger an event if desired to check the app is alive.
For the SGP4 app, it seems like it should be trivially possible to determine the app is running by looking at its telemetry. So I'm not sure I see the use case for an event to prove its working... its not typical for an app to periodically issue an event like this because all those events might cause ground operators to miss important information in the never-ending stream of aliveness events. While this is an example, given the intent is to be a semi-realistic app implementation, I'm not very excited about adding something that's too far outside of normal paradigms.
The only really useful event I could see would be implementing an event which is triggered periodically if the current FSW time is outside the range the TLE is valid for. That's something that's not currently checked for and would cause the data to be invalid, which might be something a user cares about.
I'd recommend the following implementation:
- Add a invalidity flag to the output data
- Set the invalidity to
true
for each cycle where mins the is less than TLE.epoch,false
otherwise - Add an event definition which is emitted when the invalidity flag is true, containing the current FSW time and the epoch
- Set the filter on the event to maybe once every min (see CFE filtering guide) so that this event isn't too noisy.
Since time should be settable/jammable in any desktop implementation of CFS and one can load the TLE table, this provides two methods to deliberately trigger this if desired while also adding useful functionality to the app.
Makes sense just one question, is the output data the propState_t struct?
is the output data the propState_t struct?
Correct, you can see that the output message is defined using a pointer to that structure.