Poisson-Test-Zählimpulsgenerator

[opengeiger.de]

Heute früh dachte ich mir so, bevor ich das Arduino Portenta Board wegräume, mach ich doch schnell nen Test, und ignoriere mal alle Blogs und Foren wo über den Portenta und über die Verwendung der zwei Cores fabuliert wird und teste einfach ob und wie schnell das einfache Zählprogramm läuft, wenn ich rein gar nichts dran ändere. Und siehe da, es läuft  . Der M4 Core bootet also nicht, und man arbeitet im Default auf dem 480MHz M7 ARM Core.

Ich hab dann einen Keysight 33600 Pulsgenerator genommen und 1us lange Impulse bei verschiedenen Frequenzen erzeugt und draufgegeben. Und ja, wär hätts gedacht, das Ding zählt über 100kcps ohne jeden Impulsverlust, bevor es sich dann so kurz vor 200kcps aufhängt. Das ist schon beeindruckend. Das bedeutet auch, das das Progrämmchen so von der Software her bis dahin völlig korrekt arbeitet und exakt zählt. Naja und wenn ich so an mein SBM-20 Zählrohr denke, das ich neulich in der Kapelle auf dem Killesberg vermessen habe, das macht gerade mal 3cps/(uSv/h). Das wären also dann 30mSv/h, die ich theoretisch so messen könnte, wenn das Zählrohr richtig mitkäme. Da das Zählrohr aber auch so seine Totzeit hat (ca. 100us), könnt ich mit ner Totzeit-Korrektur sogar noch mehr messen . Ich hoffe aber, das brauch ich nie   

Gut, der Portenta H7 Lite kostet eben auch seine 60+ Euro. Da wäre ein ESP32 mit 10+ Euro schon deutlich günstiger und erst recht ein Pi Pico für 4+ Euro. Aber insgesamt denke ich jetzt, ist das Problem ein Poisson-verteiltes Signal mit 10kcsp und mehr mit einem der moderneren Mikrocontrollern zu erzeugen und diese Pulse auch richtig zu zählen, erstmal gelöst. Und das müssten auch Schüler und Studenten hinbekommen. Das ist erstmal ne gute Nachricht!

Hier der verwendete Portenta H7 Sketch (ziemlich das alte) und ein paar Bilder im Anhang:

#define MAXCNT 100
volatile int counter = 0;
unsigned long oldTime = 0;

void count()
{
  counter++;
}

void setup(){
Serial.begin(9600);
attachInterrupt(digitalPinToInterrupt(D2), count, FALLING);
Serial.println("Starting");
}

void loop(){
  unsigned long time;
  unsigned long dt;
  float rate;
  if (counter == MAXCNT) {
    detachInterrupt(digitalPinToInterrupt(D2));
    time = millis();
    dt = time-oldTime;
    rate = (float)MAXCNT*1000.0/(float)dt;
    Serial.println(round(rate));
    oldTime = millis();
    counter = 0;
    attachInterrupt(digitalPinToInterrupt(D2), count, FALLING);
  }
}

[Xodor]

Wobei noch anzumerken ist, dass der ESP32 gegenüber dem RP2040 eine FPU besitzt, was gerade bei Berechnungen einen nicht zu unterschätzenden Vorteil bietet.

Ein Scintillator-Detektor mit einem ESP32 - klingt sehr interessant.

[NuclearPhoenix]

Wobei noch anzumerken ist, dass der ESP32 gegenüber dem RP2040 eine FPU besitzt, was gerade bei Berechnungen einen nicht zu unterschätzenden Vorteil bietet.

Oh ja, das stimmt. Eine FPU ist schon viel wert.

Ich frage mich, ob einem die PIOs im RP2040 was für so eine Anwendung bringen. Ich habe mich da noch nie wirklich reingedacht, aber vielleicht geht da was. Immerhin sind das ja auch quasi eigene Prozessoren für die Pins.

Ein Scintillator-Detektor mit einem ESP32 - klingt sehr interessant.

Ist vielleicht ein bisschen Overkill, aber mich würde es sehr stark wundern, wenn es sowas noch nicht gäbe. Ich meine der ESP32 ist ja einer der Mikrocontroller, die einem so als erstes einfallen -- gleich nach dem STM32...

Ich hab mir mal sagen lassen, dass der ADC vom ESP32 gar nicht so toll sein soll. Ist natürlich egal für einen Szintillationszähler, aber ist da was dran?

[Xodor]

Ja, der ADC soll wirklich nicht so gut sein und vor allem wenn er schneller betrieben wird auch sehr streuen.
Ein externer guter ADC (SPI) und eine genaue Referenz würde ich schon nehmen wenn man den über einen reinen Zähler hinaus verwenden möchte.
Auch ganz nett beim ESP32 ist ja auch, dass man WLAN und Bluetooth Konnektivität mit an Board hat - wenn man es denn benötigt.

[DL3HRT]

Ja, der ADC soll wirklich nicht so gut sein und vor allem wenn er schneller betrieben wird auch sehr streuen.

"Nicht so gut" ist stark untertrieben. Ich würde sagen, dass er unbrauchbar ist. Der ADC ist noch nicht einmal linear. Erst oberhalb einer bestimmten Spannung funktioniert er einigermaßen. Wir haben in der Firma schnell die Finger davon gelassen und arbeiten mit externen ADCs. Für Hobbyanwendungen ist der ADS1115 perfekt, weil sehr preiswert.

Wenn man aber nur zählen möchte, so sollte es auch ein schneller Comparator tun, bei dem man die Ansprechschwelle passend eingestellt hat. Ein ADC ist dazu nicht nötig.

[opengeiger.de]

So kurz vor Weihnachten, wenn die Infrastruktur der meisten Firmen runtergefahren wird, hat man ja durchaus mal Raum für etwas Forschung. Daher dachte ich, ich versuche endlich mal herauszufinden, wie das Fourier-Spektrum (die spektrale Leistungsdichte) eines Geigerzähler-Signals so aussieht.

Oder weiß das jeder, wie man das herleiten könnte?  Im Gegensatz dazu ist sicher hinreichend bekannt, wie das Fourier-Spektrum eines periodischen Rechteck-Signals eines normalen Signalgenerators aussieht. Dass dies ein Sin(x)/x bewertetes Linienspektrum ist, welches durch das Tastverhältnis bestimmt ist, lernt man in den ersten Semestern, zumindest in der Elektrotechnik. Aber wie sieht das nun aus, wenn die Pulse ganz zufällig kommen?  Manche werden da natürlich fragen, ob das nicht esoterisch sei und wozu man das bräuchte. Doch das könnte bei der Bemessung der Bandbreite einer analogen Nachbearbeitung durchaus von Bedeutung sein, zumindest wenn ein großer Kristall seine Zählimpulse mit ein paar 10kcps schickt... Und in der Datenkommunikation, da ist das von immenser Bedeutung, wobei immer angenommen wird, dass die Daten zufällig sind, zumindest fast.

Naja, und wie könnte man das besser herausfinden als mit dem Zählimpuls-Testgenerator. Daher habe ich den Zählimpuls-Generator mit Poisson-Statistik mal an eine guten Spectrum-Analyzer angeschlossen. Und tata tata tata, es kommt eigentlich was völlig Plausibles raus (was auch zeigt, dass der Zählimpuls-Generator absolut sauber funktioniert)    .

Also für die, die es schon immer wissen wollten: Das Fourier-Spektrum (Wurzel der spektralen Leistungsdichte) eines Geigerzählers ist ein gleichverteiltes, lückenloses Rauschspektrum, welches mit einem Sin(x)/x bewertet ist. Die Sin(x)/x Bewertung hat ihre Nullstellen bei N/Ti, mit N = 1...∞, wenn Ti die Breite des rechteckförmigen Zählimpulses ist. Da im gezeigten Beispiel des Zählimpuls-Generators die Impulsdauer zu 10us gewählt wurde, ergibt sich so die erste Nullstelle bei 100kHz.

Bei einem anders als rechteckig geformten Zählimpuls eines realen Zählrohrs oder Photomultipliers muss man das gleichverteilte Rauschspektrum statt mit dem Sin(x)/x Spektrum eines einzelnen Rechteck-Impulses dann eben mit dem Spektrum des realen einzelnen Detektorimpulses multiplizieren. Insgesamt bekommt man also ganz dasselbe Spektrum wie bei einer langen Pseudorandom-Zufallsfolge (PRBS) wie in der Datenkommunikation, die mit einer Periodizität von 2^31-1 abläuft und eine Datenrate von 1kbps aufweist. Das ist auch logisch, weil die Autokorrelierte von beiden Zufallssequenzen Null ist, sobald die Verschiebung mehr als Ti beträgt und bis dahin ist es eine Dreiecks-Funktion. Das ist wiederum so, weil beide ja außerhalb von Ti völlig zufällig sind, was die Lage der Zählimpulse auf der Zeitachse anbelangt. Damit hat das Fourierspektrum eine Sin(x)/x Bewertung, da das Leitungsdichte-Spektrum das Betragsquadrat davon ist, und genauso eine Sin^2(x)/x^2-Form hat, wie die PRBS (siehe Anhang).

Wenn man sich aber das Spektrum mit sehr hoher Frequenzauflösung anschauen würde, würde man natürlich merken, dass es kein ganz kontinuierliches Spektrum ist, weil sich das Zeitsignal mit 2^31-1 wiederholt, es liegt also tatsächlich doch ein sehr dicht verteiltes Linienspektrum dahinter, mit einem Linienabstand von 1/((2^31-1)*Ti), der aber im uHz Bereich liegt und daher ignoriert werden kann.

In diesem Sinne frohe Weihnachten und vielleicht macht ja sogar ein Geigerzähler etwas Musik unterm Christbaum!