Closed violetteta8 closed 5 years ago
Latest pull request has this feature added. Currently have it set to configure the burst to 1150 on set up. If the user selects any other value it should keep that value. If a value is entered that is less than 250, but not zero, then it will bring the period up to 250 since that is the minimum allowed (fastest sampling rate).
This period will show up in the burst table for our records. In the future it might be good to add a statement for the CR1000 so the period doesn't go below 1138 (or whatever period we find doesn't result in missing data). I didn't do that now so we can further test it.
Modified the store variable file to include the BurstPeriod variable so it doesn't reset to zero (and then to 1150 on the next scan) on a power cycle. Note: Having a prior USR file looks to cause the BurstPeriod to go to 250 for some reason even though there is nothing present in the USR file yet. I confirmed by setting the GetVariablesFlag to true it changes it to 250 if nothing is present for variable #39. Tested to see if it was pulling from variable #38, which was a -1, but changing the language to make -1 generate a 1150 period did not work. It still created at 250 period. Deleting the USR file seems to solve this problem.
I think we should be able to have the burst timing (set period) user selectable. Maybe for our own testing purposes. But if we made a variable ("BurstPeriod", for example) we could code that variable into the SerialOut statement:
SerialOut (WqSerialPort,"setperiod " + BurstPeriod + CHR(13) + CHR(10),"OK",3,50)
That should allow us to change it without recompiling the program. No hurry, but could be worth checking out as we move toward a pilot study.