[bladeRF-cli] save and restore device state (calibrations, gains, freqs, etc)

[lehenbauer]

Emit the calibration as a series of commands like "cal lms" and "cal dc rx" and whatnot.

[jynik]

The total list, if you wanted to do both RX and TX, would just be "cal lms", "cal dc rx", and "cal dc tx".

It seems a bit much to add a switch for just those -- perhaps I'm not quite getting the use case you had in mind?

[lehenbauer]

A sample bladeRF config file as a result of running calibration might be:

set lnagain 6
set txvga1 -35
set txvga2 0
set rxvga1 30
set rxvga2 0

cal lms tuning 23
cal lms txlpf 33 39
cal lms rxlpf 25 17
cal lms rxvga2 25 35 33 29 29
cal dc rx 246 483

To assemble that information I have to run...

cal lms
cal dc rx

...and then parse out of the verbose output of bladeRF-cli the files and then construct above quoted config.

As it is now we have a script that does indeed parse those values out and then invoke our own command line tool to load our FPGA file and configure the radio and receive data and pass it along to our downstream host code. The calibration settings are sent as command line arguments.

My understanding is that the calibration needs to be set anytime a new FPGA file is loaded, then somehow I have to run the calibration and save the calibration data. And this is how we're doing it. We're definitely up for a better approach if you've got one.

[jynik]

Thanks for elaborating -- that makes more sense. I'd imagine one might want to back up and restore frequency, bandwidth, samplerate, loopback, and other settings as well.

I have some bugs to kill to get an already delayed RC3 and release out, so I'll put this on the back burner for a bit, but would like to get it integrated. I'll think about it more and am open to ideas, but the first approach that came to mind for implementing this would be to add something like a 'print device_state' to printset.c, and then leverage that command from main.c.