Parameter Database

[sheershak-agarwal]

How do I use Parameter Database?I am asking this because I tried to connect my component to Parameter database and wasn't able to compile. So it there a guide for it?
How do I create an initial .dat file? and If I update it, will it permanently store the parameter.
Are parameter databases global or I need to create one for each component?

[LeStarch]

@timcanham can you answer this question?

[sheershak-agarwal]

Hi,

[sheershak-agarwal]

So the ParamGet is compiling fine but if I got it right, there is no way to set the parameters inside the code.
I am still a little confused. paramGet_XXX() will return the value of XXX from the PmbDb but I can't use set function. Is there a way to mimic the ground command inside a component.

My goal is to create a persistence storage for my components where it can get values from and later set it.

[sheershak-agarwal]

Could you also answer the questions on this thread's first message?

[timcanham]

There isn't a way to update the parameter, just use it. It's a safety mechanism; only the ground can change it. It avoids the software changing state without the ground knowing and commanding it.

[sheershak-agarwal]

Thank you for the clarification. Another question, How can I change the parameter from ground?

[timcanham]

You can issue the commands from the F Prime GUI,

[timcanham]

To answer your questions:

1. PrmDb is meant to store values persistently through a reboot. It allows one to changed the code's behavior without requiring a software update or repeated commanding. The PrmDb instance can serve all the components.
2. See here for some tutorials that use it.
3. You can get an initial database by issuing the _PRM_SET and then _PRM_SAVE for each of your components. That sends the values to the memory copy in PrmDb. Then issue the PRM_SAVE_FILE to save them to a file. The next time you boots, those values will be restored from disk.

[maxfirefly]

Hi @timcanham , presumably parameters are intended to have initial values, so when are those set if parameters can only be defined by a command? When a spacecraft is deployed, there is no guarantee that the ground has access to send a parameter value command, so how is the database intended to be initialized?

[maxfirefly]

Copy, so the parameter database "initialization" is even done through the ground command interface. Got it, thanks!

[maxfirefly]

As a follow up, is there a convenient way to view the "current" parameter database values? I.e. to confirm that the database is in the intended state since the PrmDb.dat files are unreadable?

[timcanham]

Yes, you have spotted a shortcoming in the system... We have:

1) Downlinked the PrmDb file and parsed it, or

2) Implemented commands for critical components to dump the values

The F Prime roadmap has a feature to add commands to dump the values to events as part of the autocoded...

[maxfirefly]

Thanks for the help--by the way, major congrats on all the successes with ingenuity over the years!

[timcanham]

Thanks, we're all proud of Ingenuity!

[ljreder]

Tim, it has been awhile but can you confirm that default parameter values are compiled in. So if you start the system we design so doing nothing brings us into a known good state for ground commands, etc. To operate.

[timcanham]

Yes, the defaults are in the autocoder, but the project has to make sure to pick the defaults so they are communicable.

[ljreder]

And of course Tim you in the process of baking in the AI so the coded parameter defaults are always correct 😉 Thanks!

[maxfirefly]

I have created a parameter, and used the GDS to run the following commands:

componentName.PARAM_NAME_PRM_SET, "VALUE"
componentName.PARAM_NAME_PRM_SAVE
prmDb.PRM_SAVE_FILE

I know these commands were successful because:

1. I am telemetering the parameter and can observe the change
2. Events are emitted documenting the success of each command
3. A file called PrmDb.dat (which didn't exist before) is created in my deployment folder

I also have instances of the prmDb component in my deployment, and included the lines in the deploymentTopology.cpp file:

prmDb.configure("PrmDb.dat");
prmDb.readParamFile();

However, when I kill the program and reboot the application/GDS, the updated value of the parameter is not retained. It reverts to whatever it defaulted as initially. It is my understanding that as long as those three commands are sent, the parameter database should be updated and saved to (which I seem to have evidence is occurring), and during boot up of the application, the PrmDb.dat file should be read to initialize all parameter database values. Thus, the parameter should have the updated value from the previous run, even after I kill the program and reboot. However, I am not seeing that occur (checking with telemetry and printouts)--am I missing a step here?

I should also note that I checked out the MathComponent tutorial and am observing the same behavior--parameter values not being stored between runs even after save commands.

[thomas-bc]

I just checked out the MathComponent tutorial and was able to save the FACTOR parameter to file (with the order of commands you specified, SET>SAVE>SAVE_FILE), kill the app, restart, and it did pick up the saved parameter.
Hard to debug without more info though...
Are you calling loadParameters() in your deployment setup?

[maxfirefly]

Wow, we had loadParameters() commented out haha. Thanks for that!

[thomas-bc]

Yeah the fprime-util new --deployment comments it out because (if I remember correctly) the function isn't generated if there's no parameter to be loaded. There might be room for improvement there in some way

[maxfirefly]

Ah, that makes to me. Thanks Thomas!