[hpsdr] Database reset = loss of calibration data?

[Brian Lloyd]

On Sat, Jul 12, 2014 at 9:07 AM, Hermann <hvh.net at gmail.com> wrote:

> ***** High Performance Software Defined Radio Discussion List *****
>
>
>
>
> On Sat, Jul 12, 2014 at 3:51 PM, Brian Lloyd <brian at lloyd.com> wrote:
>
>> ***** High Performance Software Defined Radio Discussion List *****
>>
>>
>> I suggested a very simple hack -- a version number in the database file
>> or, better still, for each logical section of the database file -- but I
>> think Greg's suggestion, while more difficult to do the first time, is a
>> far more universal solution. The database is just a collection of
>> attribute/value tuples. It wouldn't be too hard to have a "rationality
>> checker" for each A/V pair when it is read in during system initialization.
>>
>>
>
> Unfortunately its not only checking the validity of an A/V pair. This is
> easy and I think this is alreday done. The problem is the combinatorical
> explosion of A/V paris among each other. While loading the database each
> possible mode of the software has to be checked, which correspond to a
> certain subset of A/V pairs. It's like an exhaustive testing of a big state
> machine, which might take a while, and which is not so easily implemented.
> Furthermore, this state machine is increasing with each new version.
>

Yes, you are right if you assume that the probability is that every A/V
pair is stateful with respect to every other A/V pair. But for many of the
A/V pairs this is not the case, hence my suggestion that one put version
numbers in the various sections. Do you think that PA gain calibration is
stateful WRT everything else? I don't. It would probably be pretty easy to
break that off into its own section of the DB and flag it separately. And
for those that obviously are, blow them away and replace them with default
values when the version number increments.

So it is possible to address this problem incrementally, with each
increment adding more value to the user. Just adding a version number,
checking that, and deleting the old DB if the version numbers don't match
would help a LOT and be a relatively small amount of code. Version numbers
for functional sections of the DB would be incrementally more difficult but
would incrementally add function.

-- 
Brian Lloyd
Lloyd Aviation
706 Flightline Drive
Spring Branch, TX 78070
brian at lloyd.com
+1.916.877.5067
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20140712/f08461fd/attachment-0003.htm>