Storing Parameters when the satellite is not in contact with any groundstation

[rawinza555]

Hi, I'm trying to implement some sort of local database that can store some housekeeping data when the satellite is not in view of a groundstation. This way, space ops crews can pull the data to see if there's any anomaly before then.

In the beginning, I tried to look at prmdb since it is mentioned in Math Component but turned out it's more like a way to store parameters so that it would not be affected if the OBC is rebooted. Is there a way to modify it to work or if F' has something that can perform this task?

If there's none and I have to make one, what would be your recommendation on how to do this from scratch? I imagined I could have a component that create a txt file to write on then I can use filedownlink to download them to the ground station but I'm open for any recommendation.

[timcanham]

@rawinza555: There is a component Svc/ComLogger that you can attached to your telemetry (Svc/TlmChan) or event (Svc/ActiveLogger) packet output ports (you can use Svc/ComSplitter to split the packet stream). The ComLogger component will write any packets it gets to the file system (assuming you have a file system). You can then download the ComLogger file later and get any telemetry that was produced when you are out of view of your ground station.

[rawinza555]

Thanks Tim! This is definitely what I'm looking for.
If, let's say, I want to only have it logging sensor data every few seconds or few minutes to save storage space, what would be the best way to configure comlogger? I'm wondering if I could have comlogger hooked with a rate group driver that run at 0.5 Hz so I can have a telemetry logged at every 2 seconds. Or do you think it's a better idea to have a sensor component that can switch between two different rate group, depending on whether it is in view of the ground or not?

[timcanham]

ComLogger is currently an active component that is driven by the production of packets from whatever source its connected to, so you would have to modify the production rate at the source. If we use Svc/TlmChan as the source component, it produces telemetry based on how often its Run port is called, which is typically (as it is in the Ref example) called by Svc/ActiveRateGroup. I wouldn't recommend modifying ActiveRateGroup, TlmChan, or ComLogger, but if you wanted to modally change the rate at which telemetry is produced you could drive the ActiveRateGroup connected to TlmChan at a variable rate. If you wanted to be clever in an F Prime tinker-toy kind of way, you could insert a component between ActiveRateGroup and TlmChan with a command to skip every nth cycle. You could make it run full rate when you are in view, and slower when you are not. That would limit the overall rate of telemetry production, including your sensor. You could also do what you suggested and have the sensor produce data at a slower rate, but that would just lower the sensor's rate and not the rate of other telemetry in the system.

[rawinza555]

I have follow up questions @timcanham. I have tried out ComLogger by connecting comsplitter to tlmchan then have one goes to framer and other one goes to comlogger, just to check out file format and how it stored values using Ref. I see that in text file have a space delim between two bytes of data and it starts a new line every 16 bytes per line, regardless of how long the telemetry packet size actually is. I'm wondering if there's a way to change the way the file is written so that the entire telemetry packet is in one line and every byte is separated by a space.

I imagined that if it is formatted this way, I can easily identify the channel code so I can compare time stamp of the telemetry in the file vs the incoming data. Then I can set a threshold that if it has been longer than X seconds, it will write it in a file.

[timcanham]

It's on our "to-do" list to write a file decoder. You have to use the dictionary file to match channel ID to telemetry type in order to convert the data correctly. Want to volunteer? :)

[rawinza555]

As a matter of fact, I'm working on something along this line as well. It's supposed to be a python script that can be integrated to openmct so our team can have some nice data formatted to look at, all in one place.

If you meant some sort of algorithm to be used onboard the flight computer then it shouldn't be that hard to implement. I will keep you all posted. At least it's something I can do to help you guys maintaining this amazing framework!

[rawinza555]

In case anyone is wondering, what I have done is, similar to what @timcanham suggested, I inserted a component between rategroup1 and tlmchan and a comsplitter from tlmchan to framer and comlogger.

For the first iteration, this new component is a queued component that have one command to adjust data write rate. The component initialize with a default write rate and a reference timestamp which initialize at during the initialization. If the time difference between current time stamp and a reference time stamp is greater than data write rate, it will drive tlmchan. Otherwise it will do nothing.

In the next iteration, I will implement a two operational mode (think of it like a day/night scene in home automation system) that is triggered by an input from comm driver (TCP/IP or radio module, I'm still looking at the technical detail of it). It will run full rate if is in "in view" mode and drive at slower rate at "Not in view mode".
I am also planning on adding filtering capability to comlogger by only recording certain telemetry during the "not in view mode". Hopefully it can help driving down the size of the file.

Not sure why suddenly I can't mark the answer........

[timcanham]

Very good! If you don't want to depend on time, you could also just use a counter in the component that would skip n cycles before invoking TlmChan.

[rawinza555]

From your experience in this field, for this particular application, is there any advantage on doing this base on cycle count over time or vice versa? Perhaps clock drift if not using csac on board but I don't read know.

[timcanham]

I try to decouple from clock time when I can, because not all platforms have a notion of time. It makes the components more portable.