20220719
========
Anders har fixat så att NIM -> TTL fungerar med pulsgeneratorn.
Tog bort 50 ohm termineringsmotståndet på NIM på TTL omvandlaren
för att få upp NIM signalen i nivå för att trigga pulsgeneratorn.

12 pulser ska synas med 60 samples mellan topparna (3 mikrosekonder) i
udda kanaler.


Uppställning:
SRU trigger -> testpuls -> pulsgenerator -> 12 trappsteg

Tidssvep för två events:
protomcm-evt1-run35-pulses-10ns.pdf
protomcm-evt2-run35-pulses-10ns.pdf

Normerat tidssvep för alla events:
protomcm-norm-35-10ns.pdf

Normerat tidssvep förstorat vid maxvärdet
(OBS ingen hänsyn till peaktype enligt nedan):
protomcm-norm-35-10ns-top.pdf

En viss struktur kan kanske ses för toppvärdet av de olika pulserna.
Beror det på ändrade strömmar genom refspänningarna och därmed ändras
refspäninngarna?
Man skulle kunna jämföra hur baslinnjen varierar på de kanaler
som inte pulsas, men det verkar för stökigt för att kunna dra någon slutsats.

Testpulsen är synkad med triggern och med SRU klockan som är på 40Mz.
Eftersom SALTRO samplingsklockan är på 20 MHz, kan testpulsen därför hoppa med
25 ns relativt samplingsklockan.
Det kan ses i första pulsen för två olika event. 
protomcm-evt1-run35-pulses-10ns-puls1.pdf
protomcm-evt2-run35-pulses-10ns-puls1.pdf

Det är inte mycket att göra åt.
För att bestämma vilken sampling som gäller för ett event
kan man studera första pulsen i pulståget.
Delayer är satta så att en sampel
1. sker på toppen av pulsen
eller
2. att toppen är mellan två samples.

exempel:
Man kan jämföra adcvärdet där toppen förväntas vara (peaktime nedan) med
de närliggande samplena (iSamples nedan) och att topvärdet ska vara
över en tröskel.
Enkel algoritm:

// Default ingen peak i första pulsen
peaktype = 0;
// samplas på toppen
if ((iSamples[peaktime] - iSamples[peaktime+1] > 15) &&
    (iSamples[peaktime] - iSamples[peaktime-1] > 15) &&
    (iSamples[peaktime] > peakthr)) {
        peaktype = 1;
}
// toppen mellan två sampels
else if (((abs(iSamples[peaktime] - iSamples[peaktime+1]) < 15) ||
          (abs(iSamples[peaktime] - iSamples[peaktime-1]) < 15)) &&
          (iSamples[peaktime] > peakthr)) {
            peaktype = 2;
}
Kan givetvis optimeras bättre, speciellt för att ta hänsyn till
olika shapingtider.

Plottade ADC värdena för de olika "peaktype"
0 - ingen peak hittad
1 - på toppen av pulsen
2 - samples på var sin sida om pulsens top
Summerat över alla 12 pulser i pulståget (antar 60 samples mellan pulserna,
dvs sample = peaktime + 60*pulsnummer)
och alla events per kanal.
protomcm-run35-peaktype0-test.pdf
protomcm-run35-peaktype1-test.pdf
protomcm-run35-peaktype2-test.pdf


Från peaktime0 syns att algoritmen missar några toppar som ska vara peaktime1.
Från peaktime1 syns att algoritmen inte tolkar ett 'peaktime' sample på peaken
som vid ett sidan om peaken, dvs som peaktime2.
Från peaktime2 syns att algoritmen inte tolkar ett 'peaktime'
sample utanför peaken som ett på peaken dvs som peaktime1.

Ej gjort:
rms är rätt små, bör jämföras med rms på baslinjen dvs
värdena mellan pulserna (tex ett antal sampels innan pulsen).
Subtrahera baslinjen från pulsen.

Se plot mellan två pulser:
protomcm-evt1-run35-pulses-puls2.pdf

Titta på pulserna individuellt.
etc ...