CRDS PMT acquisition not capturign ringdowns

[JustinLangridge]

Appears to be an issue the timing on the PMT signal acquisition. The waveform data is not capturing the ringdown events.

For example, for Blue dry we are capturing the ring up period. This is being fit to retrieve a reasonable ringdown time of around 20 microseconds. We are capturing around 400 samples

For the Blue gas channel (which is going into the slower 6132), it looks like we're capturing either zero periods or multiple ring up and down periods.

[JustinLangridge]

This is what the waveform returns look like currently. Note that all 4 of these cells are aligned (verified by putting output straight into a scope) .

This picture does change, for example the number of points acquired has flipped between 400 and around 2000 (as below). When the number of points acquired was 400, the blue channels ring ups were being fitted.

[lo-co]

Hmmmm...I am not totally following this (I mean I am but...). Wasn't this working before? I seem to have recalled seeing the actual RDs at one point. Did something change or is my memory bad?

[JustinLangridge]

I don't think we've ever had actual ringdowns coming through - we didn't have cells aligned when you were over or since until now.

Maybe this is related to issue #92 in lo-co/exscalabar. This issue is closed but we commented on potential downstream impacts from re-ordering the CRD PMT AI channels in Get Data. You were going to look in to this.

Note the actual channel assignments are as follows and the 6124 inputs are from both blue and red channels:

Dry blue: 6124_AI0 Blue gas: 6132_AI0 high RH: 6124_AI1 med RH: 6124_AI2 red dry: 6124_AI3

[lo-co]

After looking at this for some time, it seems that the sampling is triggering 1x (we get 4x1000 samples and then errors indicating that the trigger is not rearming). Needs more attention.

[lo-co]

Going to add something to the server to try to reset the AI acquisition if we are not retrieving in the right place.

[lo-co]

Works