Closed stillwer closed 6 years ago
Are we talking about the control in labview operations, the raw files, the merged files, or some combination of the three?
Is the 5ns clock you are referring to the MCS internal clock?
Just to be clear the new variable would be something like "Counts per X meters in range", correct?
Is there a reason Scott couldn't talk to me about this concern directly that is causing you to be the middle man? If so we need to work that out because there's no reason why this couldn't have been discussed with me directly.
Labview for sure. The rest...not sure? I would ask him if you are in the office or I can do it tomorrow. It is just more user friendly.
The 5 ns clock is the MCS internal clock...yes.
I see the variable being something like "Range Resolution" and having the code on the back end interpret that and send it to the MCS. So if you put 37 meters for example, the closest we can get is 37.5 which is 250 ns which is 50 clock counts.
Scott mentioned it last time he was playing with the labview (2 weeks ago or so) when I was in the lab. I forgot to document it until today. No other reason but I was standing there when he thought of it.
Ok, i've been looking for scott today, his office door has been open but he hasn't been there. I have to catch him at some point this week anyway. Thanks for the submission.
ok, switched so time is used instead of number of clock cycles in the raw and merged files. This change is on my local build at the moment, and i'll make the change in labview independently in a moment.
In talking to Scott, he prefers to have the MCS range resolution preset in meters or in time. Now it is currently listed as "Counts Per Bin". His preference is to have that as meters or time and not have to multiple by the 5 ns clock rate.