Missed pulses in long term tests
When running the long-term tests with a separate CONV-TTL-BLO system, boards seem to start missing pulses.
The figure is not alarming, out of 7068 out of 27 billion pulses, yielding 0.25 ppm loss, but the issue should be investigated nonetheless.
The setup for the test is as shown below:
Pulses get sent out of the stimulus CONV-TTL-BLO on channel six at varying frequencies, in the range 150 to 166 kHz. These pulses are replicated through the DUT CONV-TTL-BLO and retrieved on the input of the stimulus system. Counters on the stimulus system check the number of pulses sent out of channel six and those received on channel one.
A Python program (test/pulsetest/pulsetest.py) is used to command the stimulus system. The program starts by asking the user which channel to enable and for the frequency on the enabled channels, sends the frequency value to the corresponding channel pulse generator, and enables pulse generation. At the end of the test, the program reads out the value of the counters and outputs them to a log file.
Three files contain different values on channel 1 input counter and channel 6 output counters, resulting in missed pulses. These files are:
- p-2013-09-20-18h53.txt - 3673 pulses
- p-2013-09-25-09h07.txt - 1 pulse
- p-2013-09-25-19h23.txt - 3394 pulses
The interesting thing is that in the case of the first and last test which yielded missing pulses, pulse generation was not stopped after the test finished. That is to say, the command the Python program sends to stop pulse generation did not get interpreted.
This leads to one of three possible reasons for the "missed" pulses:
- there is a problem with the vbcp_wb bridge component
- the Python program somehow sends a wrong command to the ELMA crate
- the ELMA crate does not interpret the command properly and thus doesn't send it to the stimulus CONV-TTL-BLO
It therefore seems that the pulse generation logic and hardware is not the problem here. Tests run on the vbcp_wb component using the communication test did not yield any problems (no wrong commands were detected, no mismatch in writes to addresses).
More runs of the tests have to be performed in order to determine the problem.