Reading the latest message from a high rate publisher

[9a3eedi]

I have an app that reads data from an IMU and publishes the data at a high rate (for example, 8Hz). I have another app that runs at a lower rate and doesn't need to read all of the data that comes out of the IMU app, but only needs to read the latest information at 1Hz.

If the second app subscribes to the data, then it would need to constantly read data that it doesn't need to prevent the pipe from filling up, and is a waste of CPU cycles if I understand correctly. My current workaround is to have a pipe size of 1, which will cause it to constantly overflow and drop new data. Then, when it's time to read the latest data, it would simply do a read twice: once to read what's in the pipe (clearing it), and then one more time to get the latest.

This is very ugly in my opinion, and generates unnecessary error messages, and I was wondering if there's a better way of handling it within the cFE framework. I get the feeling that I'm going about this the wrong way.

[skliper]

Answer depends on what else depends on or uses that data. I see the following options:

1. Decimate at the source: if nothing else needs 8 Hz data, no need to produce it at that rate
2. Decimate via HK app: I think HK can produce a summary or decimated packet at the 1Hz rate that the 2nd app could subscribe to, this would probably best fit a model where something else might want the high and low rate data (or you want to see it in TLM). This is handy since then you can see exactly what the lower rate app is processing.
3. Decimate at the sink: Make the pipe big enough to fit all the packets, but discard the older ones. Either service it at your lower rate wake up (implies wake up pipe and a data pipe). Or if you do it w/ a single pipe and just wake up at every message your app could process the the next IMU packet arrival after a wake up and discard the rest, or store the previous IMU packet (adds a copy) and process it when the wake up arrives. If you do it with separate pipes and service at the lower rate it'll use more of the SB memory pool for the high rate data.

[excaliburtb]

depending on your capacity for available message IDs, I'd add a fourth option to @skliper for the source app to produce both an 8 Hz packet and a 1Hz packet with 2 different MIDs if you don't want to send it to HK just to retransmit. We used this for a couple of cases on our Orion backup flight software project and it worked well for us.