Das Openmess-Projekt

[Flipflop]

Kalibrierlabor für Geräte gibt es sicher auch DE. Hier etwas von der Firma Gihmm

https://www.gihmm.at/kalibrierlabor/

[Peter-1]

Bitte nicht falsch verstehen. Es geht nicht um die Genauigkeit, sondern um die Frage wieso ein Bauteil außerhalb der vom Hersteller genannten Spezifikation in einem "amtlichen" Meßgerät betrieben werden darf. Das klingt für mich, dass das BfS sich über die Herstellerangaben hinweg setzt.
Sicher durch undurchdringlichen § Dschungel geregelt.

[NoLi]

Immer wieder tauchen Fragen auf.
a)  Sind die ODL Sonden geeicht oder nur kalibriert?
b)  der Meßbereich für die 70031A wird von 0,2µSv/h bis 3000µSv/h angegeben.
    Die ODL auf der FINO 3 in der Nordsee zeigt z.Zt. 0,036µSv/h an.
   
Ein offizieller Wert der Sonde, aber weit außerhalb des Meßbereichs. 
Oder werden besondere ZR eingesetzt?
Ich habe da ein leichtes Verständnisproblem.
...

Wenn nicht auf der Sonde am Übergang Sondenhülle - Standrohr ein Siegel solcher oder ähnlicher Art angebracht ist, sind die Sonden kalibriert und nicht geeicht:

Ich denke, eichen kann nur das Eichamt.

Und diese geringen Messwerte werden ja durch Mittelung über einen längeren Zeitraum ermittelt. War das nicht eine halbe Stunde? Die OdL Sonde meines Vertrauens zeigt eigentlich durchgehend 0,060μSv/h an.

Genau, eichen macht ein Beamter des Eichamtes, kalibrieren macht ein Fachmann...

Die Mittelungszeit der BfS-Sonden liegt im Routinebetrieb bei 2 Stunden.

Die Messwerte der BfS-Sonden bei < 0,2 µSv/h können durchaus korrekt sein, insbesondere bei längerer Integral-Mittelungszeit; bei deutlich kürzeren Integral-Messzeiten oder gar im Ratemeter-Betrieb kann der Messfehler aber durchaus größer als die erlaubten Toleranzgrenzen werden.

Norbert

[NoLi]

Bitte nicht falsch verstehen. Es geht nicht um die Genauigkeit, sondern um die Frage wieso ein Bauteil außerhalb der vom Hersteller genannten Spezifikation in einem "amtlichen" Meßgerät betrieben werden darf. Das klingt für mich, dass das BfS sich über die Herstellerangaben hinweg setzt.
Sicher durch undurchdringlichen § Dschungel geregelt.

Beides, Genauigkeit und spezifische Daten, hängen zusammen.

Solange durch messtechnische "Kniffe" zur Verbesserung der statistischen Genauigkeit, wie die Impulsintegration über 2 Stunden und daraus Mittelwertbildung, die erlaubten Fehlergrenzen eingehalten werden können, warum nicht betreiben?
Der Hersteller gibt nur Grunddaten an, die im ungünstigsten Fall -hier der Ratemeter-Betrieb- gelten würden. Er weiß ja nicht, wie das Zählrohr später beim Kunden betrieben werden wird.

Norbert

[DL8BCN]

Wenn Bernd die finale Version fertig hat, wäre es super noch mal eine Zusammenfassung des Projekts zu haben, um den Nachbau zu erleichtern.
Speziell was den Mikroprozessor und die Software dafür angeht, habe ich sehr wenig Ahnung
Da ich ein 70031A besitze, könnte ich mir gut vorstellen das Projekt nachzubauen.

[NoLi]

  Die OM01-Sonde läuft! 2.47cps

Sie dürfen in diesem Board keine Dateianhänge sehen.

Was mir aufgefallen ist: soviel Schnee in Stuttgart? Bei uns ist nix weiß...

Norbert

[opengeiger.de]

Ich werde definitiv ein Dokument als Zusammenfassung schreiben. Und wenn ich nun weiß, dass der Mikrocontroller wichtig ist, dann werde ich das berücksichtigen. Was ich heute früh fotografiert habe, und ja es hat hier Schnee und heute früh hatte es -6°C, ist erstmal der Lab-Prototype (LP). Der Produktion Prototype (PP) wird vielleicht noch ein wenig anders aussehen. Beim diesem LP ist die Basis-Platte ein 3mm Sperrholzplatte mit 3mm Schaumstoffunterlage, die auf der Rückseite mit einer Kantleiste stabilisiert ist. Ob das so bleibt, wird sich noch zeigen müssen. Was ich definitiv auf den Arduino noch draufsetze ist ein Datalogging Shield, so dass die Messdaten auf SD-Karte gespeichert werden. Und dann werden sich im Betrieb sicher noch weitere Verbesserungsmöglichkeiten ergeben. Und für Inputs bin ich immer offen. 

[opengeiger.de]

Mittlerweile läuft jetzt auch das Loggen der Daten auf SD-Karte.

Sie dürfen in diesem Board keine Dateianhänge sehen.

Deswegen will ich hier nun den derzeitigen Code posten. Ich habe die .ino Datei in eine Text Datei umbenannt und angehängt. Zunächst aber mal der grobe Aufbau des Lab-Prototype der OM01. Im ,,richtigen Leben" darf ein Lab-Prototype auch noch Sperrholz enthalten, um z.B. Gehäuseteile anzudeuten, das wird allerdings zunehmend durch Teile aus dem 3D-Drucker ersetzt, wobei man in der Zwischenzeit bekanntlich auch Metall drucken kann. Auf einer Platine dürften da auch noch Fädeldrähte drauf sein, und man darf auch SMD-Bauteile noch ,,huckepack" löten und solche Sachen machen. Hier ist das Sperrholz aber auch dem Input von @NoLi geschuldet, da wir ja keine Gamma-Quanten im Gehäuse-Material abfangen wollen. Ich könnte mir aber denken, dass eine Produktionsabteilung im richtigen Leben eine Kohlefaser-Platte aus dem Modellbau akzeptieren würde, die sich gegenüber der Gamma-Strahlung auch sehr neutral verhalten sollte. Und das kann man auch im Hobby-Bereich dann für einen ,,Production Prototype" gut einsetzen, nachdem man dann weiß, dass alles richtig tut. Auch für die Schaumauflage könnte man Silikonschaum nehmen, man braucht die Elastizität, damit die Kabelbinder das VacuTec 70031A Zählrohr sicher und rotationsfest halten. Es dürfen jedenfalls bei Bewegung der Sonde keinerlei Kräfte auf die Anschlusskabel wirken.

Die Elektronik besteht aus dem Theremino-Board, das vom Arduino her mit 5V versorgt wird und dessen Signal Out auf den Interrupt 0 Eingang (Pin 2) des Arduino Uno geführt ist. Als Display habe ich ein einfaches I2C Display mit 2x16 Zeichen und Backlight benutzt, das auch vom Arduino versorgt wird. Es stammt von Seeedstudio und ist aus der Grove Serie. Dazu gibt es auch eine sehr einfache Arduino Bibliothek, die ich verwendet habe. Dann haben wir noch den Arduino Uno selbst, den ich in der Rev. 3 verwendet habe (mit Atmel-Prozessor), mittlerweile gibt es einen Rev. 4 mit Renesas-Prozessor, der kompatibel sein soll. Das Rev. 4 Board habe ich aber noch nicht getestet und ganz kompatibel wird es auch nicht sein, das würde mich wundern. Auf dem Arduino steckt nun ein Datalogging Shield der Firma Adafruit. Da ist eine Real Time Clock des Typs PCF8523 drauf, ein SD-Kartenhalter sowie eine Halterung für eine CR1220 Data Retention Batterie (Lithium 3V) damit die Uhr die Zeit nicht vergisst. Auch für dieses Shield bekommt man von Adafruit eine gute Bibliothek für diese Komponenten, die ich verwendet habe. Anstelle der meist mitgelieferten Stiftleisten würde ich empfehlen Buchsenleisten mit langen Stiften einzulöten, damit man oben nochmal was aufstecken kann. Denn es gibt beispielsweise noch GPS-Shields, damit bekäme man nämlich auch noch die Geodaten zu den Messdaten, was auch nicht ganz verkehrt wäre. Aber wir wollen es am Anfang ja nicht übertreiben, viele Profigeräte haben auch keine Georeferenzierung der Messdaten.
 
Sie dürfen in diesem Board keine Dateianhänge sehen.

Nun zum Code (auf Wunsch etwas ausführlicher). Zunächst mal die Compileranweisungen:

#define MAXCNT 100
#define PIEZO 7
#define DEBUG 0

#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include "RTClib.h"
#include "rgb_lcd.h"

MAXCNT soll der Compiler durch 100 ersetzen, das ist die Anzahl der Impulse auf die gewartet wird, bevor eine Zählimpulsrate berechnet wird. Die OM01-Sonde verwendet also eine Impulsvorwahl, die dafür sorgt, dass man den statistischen Fehler von vorneherein kennt. Er beträgt dann 10%. Wenn man will, kann man einen Piezo auf Pin 7 als Ticker anschließen, das ist später im Code dann aber auskommentiert, da das eine zusätzliche Totzeit von 5 Millisekunden erzeugt. Das würde ich nur fürs Debugging aktivieren, sonst wird man bei hohen Zählraten dadurch Zählimpulse verlieren und die Messung wird ungenau. Die DEBUG Anweisung steht auf Null und verhindert, dass Ergebnisse auch auf einen Computermonitor geschrieben werden, weil das ebenfalls Zeit kostet. Da das aber nur während der Auswertung gemacht werden würde, wäre es für die Qualität der Messung keine Einschränkung. Setzt man DEBUG auf 1, kann man im Serial Monitor der Arduino IDE mitlesen, was auf die SD-Karte geschrieben wird.

Danach folgen die Anweisungen zum Einbinden der Bibliotheken. Wire ist eine Arduino-Bibliothek für den I2C-Bus, der vom Display verwendet wird, SPI und SD sind auch Arduino-Bibliotheken für die SD-Karte, die über einen SPI Bus mit dem Prozessor redet. RTClib stammt von Adafruit und ist die Biblothek für die Realtime-Clock. Die Bibliothek rgb_lcd schließlich stammt von Seedstudio und ist der Softwaretreiber fürs Display. RTClib und rgb_lcd muss man sich bei den Herstellern runterladen und explizit ins Arduino Bibliothekenverzeichnis stellen, sonst meckert der Compiler. 

volatile int counter = 0;
unsigned long oldTime = 0;
//RTC_DS1307 rtc;
RTC_PCF8523 rtc;
char fileName[15] = "datalog.txt";
File myFile;

rgb_lcd lcd;

Als globale Variable wird counter vereinbart, das ist der Zähler für die Zählimpulse. Die Variable oldTime speichert die Zeit nach einer Auswertung, damit die Zählimpulsrate aus der Zeitdifferenz zwischen der neuen Zeit und der gespeicherten alten Zeit berechnet werden kann. Das ist jetzt also das Messzeitintervall. Die Variable RTC_PCF8523 ist vom Datentyp rtc, das ist von der Real-Time Bibliothek so vorgegeben. Ältere Shields haben statt des PCF8523 ICs noch den DS1307 von Dallas drauf, deswegen ist das noch als Kommentar drin. Beim Schreiben des Datalog-Files auf die SD Karten nehme ich immer den Namen ,,datalog.txt", das ist hier auch als Character-Feld mit 15 Zeichen vereinbart. Die Datei selbst verwendet myFile als Variable vom Typ File.

void count()
{
  counter++;
  /*
  digitalWrite(PIEZO,HIGH);
  delay(5);
  digitalWrite(PIEZO,LOW);
  */
}

Die Count Routine ist nun die wichtigste Routine, die auch absolut zeitkritisch ist. Bei höheren Zählimpulsraten darf hier eigentlich nur der Zähler für die Zählimpulse mit counter++ erhöht werden. Sonst darf hierin nichts passieren, was Zeit kostet, denn in dieser Zeit muss der Prozessor weitere durch Zählimpulse eintreffende Interrupts in die Warteschleife schieben, und das kann er nur in begrenztem Umfang, und dann muss er sie auch noch abgearbeitet bekommen. Wenn er das nicht schafft, dann verliert er sie und das erzeugt eine zusätzliche Totzeit. Nun taktet der Prozessor beim Uno zwar mit 16 MHz, aber im auskommentierten Code für den Piezo Click steht nun delay(5) als Anweisung, was eine Wartezeit von 5ms erzwingt um die Membran des Piezo-Tickers zu bewegen, sonst hört man ihn nämlich nicht. Und in 5ms, da können bei hoher Zählrate schon ein paar Zählimpulse reinkommen. Wenn man ein Ticken erzeugen will sollte man das besser mit Hardware tun und nicht mit Software in der Zählroutine. Das hier dient nur dem Debugging und man wird es bei Raten unter 100cps im Messergebnis nicht merken, darüber aber schon. Ich kenne auch keine Profisonde, die einen Ticker hat, da würden ja die Leute davonrennen und die Polizei rufen.

void setup()
{ 
  pinMode(PIEZO, OUTPUT);
  digitalWrite(PIEZO,LOW);

  lcd.begin(16, 2);
  lcd.print(MAXCNT);
  lcd.print("P ");
  lcd.print("cps:");
  lcd.setCursor(0, 1);   
  lcd.print(" ");
  lcd.setCursor(0, 1);   
  lcd.print(counter);

  Wire.begin();
  pinMode(10, OUTPUT); // SD Card CS
  Serial.begin(9600);


  if (! rtc.begin()) {
    Serial.println("Couldn't find RTC");
    while (1);
  }
  //if (! rtc.isrunning()) {    //DS1307
  if (! rtc.initialized()) {
    Serial.println("RTC is NOT running!");
  }
  //rtc.adjust(DateTime(F(__DATE__), F(__TIME__)));

  if (!SD.begin(10)) {
    Serial.println("SDcard not ready");
  }
  else
    Serial.println("SDcard ok");
 
  if (!SD.exists(fileName)) {
    myFile = SD.open(fileName, FILE_WRITE);
    myFile.println("###");
    myFile.flush();
  }
  else {
    myFile = SD.open(fileName, FILE_WRITE);
    myFile.println("-----");
    myFile.flush();
  } 
  Serial.println("Logging started ...");
 
  attachInterrupt(0, count, FALLING);
}

In der Setup-Routine, die bei Programmstart nur einmal ausgeführt wird, werden nun alle Initialisierungen, die notwendig sind, gemacht. Zuerst wird der IO-Pin für den Piezo auf Ausgabe geschaltet und auf 0V gelegt, der ist per default sonst ein Input. Dann wird mit der lcd.begin() Methode das Display initialisiert und der Wert von MAXCNT und dem Zeichen ,,P" für Pulse ausgegeben, gefolgt von dem Text cps: damit man weiß dass nun eine Zählrate folgt. Sobald man eine gültige Kalibrierung hat, könnte man auch anstelle dessen eine Dosisleistung rausgeben. Die Kalibrierung haben wir aber noch nicht, das kommt erst noch. Das Display zählt seine Zeilen und Characters immer beginnend bei 0 und lcd.setCursor(0, 1);   setzt den Schreibcursor beispielsweise auf das erste Zeichen in der zweiten Zeile. Danach wird der Impuls-Zählerstand ausgegeben, der hier noch Null ist. 

Dann wird die SD-Karte initialisiert, die auf dem PCB des Adafruit Shield am Arduino Pin 10 angeschlossen ist. Falls man etwas auf dem Bildschirm ausgeben will, wird mit Serial.begin(9600) die Arduino UART aktiviert, welche die ASCII-Zeichen mit 9600Zeichen/s zum COM-Port des Computers überträgt. Das kann man dann mit dem Serial Monitor in der Arduino IDE anschauen, aber auch mit jedem anderen ASCII Terminal Programm.

Danach wird die Echtzeit-Uhr initialisiert und auf die Computer-Uhr synchronisiert, aber nur, wenn man die Zeile
rtc.adjust(DateTime(F(__DATE__), F(__TIME__)));
nicht auskommentiert hat. Das Kommentar muss man einmal entfernen um die Uhr zu stellen und dann nochmal mit Kommentar übersetzen, damit er von da ab die eigenen Uhrendaten verwendet. Hier habe ich den Code für den älteren DS1307 Chip noch als Kommentar drin gelassen.

Danach wird die SD-Karte initialisiert. Ich frage zuerst ab, ob sie drinsteckt oder ob sie sonst irgendwelche Probleme hat. Erst dann hole ich mir mit SD.open() den File-Identifier zum Schreiben auf datalog.txt und schreibe erstmal drei # in eine Zeile, dass man später sieht, dass der Beginn des Logvorgangs auch auf der Karte der Beginn der Datenaufzeichnung ist. Falls es schon einen datalog.txt File gibt, schreibe ich ,,-----,, als Trennzeile, daran erkennt man später, dass ab da eine neue Messdatensequenz geloggt wurde. Ich lösche alte Daten nämlich nicht weg, sondern hänge neue Daten an den bestehenden Logfile an. Löschen muss man einen Datalog-File auf der SD-Karte mit dem Computer, nach dem Postprocessing. Man muss nachdem man Daten auf die SD-Karte geschrieben hat den Schreibpuffer auch immer leeren, damit alles auf der Karte steht, das macht man mit myFile.flush();

Jetzt folgt noch eine wichtige Zeile, die das Interrupt-Handling für den Interrupt-Eingang 0 mit der fallenden Flanke der Zählimpulse scharf macht. Ab hier löst ein am Pin 2 Eingang eintreffender Impuls das Pausieren des normalen Programmablaufs aus und verzweigt in die count() Routine temporär um den Zählimpuls zu zählen um dann wieder mit der normalen Programmausführung fortzufahren.
Nach Ausführen der Setup() Routine wird die Routine loop() periodisch wiederholt, bis ein Reset eintrifft oder der Versorgungsstrom abgestellt wird. Loop() stellt daher den normalen Programmablauf dar, solange kein Interrupt ausgelöst wird.
 
void loop()
{
  unsigned long time;
  unsigned long dt;
  float rate;
  if (counter >= MAXCNT) {
    detachInterrupt(0);
    time = millis();
    dt = time-oldTime;
    rate = (float)MAXCNT*1000.0/(float)dt;
    lcd.setCursor(0, 1);
    lcd.print("        ");
    lcd.setCursor(0, 1);
    lcd.print(rate);
    oldTime = time;
    counter = 0;

    //logging
    DateTime now = rtc.now();

    if(DEBUG) {
      Serial.print(now.day());
      Serial.print('.');
      Serial.print(now.month());
      Serial.print('.');
      Serial.print(now.year());
      Serial.print(' ');
      Serial.print(now.hour());
      Serial.print(':');
      Serial.print(now.minute());
      Serial.print(':');
      Serial.print(now.second());
      Serial.print(' ');
      Serial.print(rate);     
      Serial.println();
  }   

    myFile.print(now.day(), DEC);
    myFile.print('.');
    myFile.print(now.month(), DEC);
    myFile.print('.');
    myFile.print(now.year(), DEC);
    myFile.print(' ');
    myFile.print(now.hour(), DEC);
    myFile.print(':');
    myFile.print(now.minute(), DEC);
    myFile.print(':');
    myFile.print(now.second(), DEC);
    myFile.print('\t');
    myFile.print(rate);     
   
    myFile.println();
    myFile.flush();   
    attachInterrupt(0, count, FALLING);
  }
}

Die meiste Zeit passiert in der loop() Routine nichts, weil nämlich die Anweisung if (counter >= MAXCNT) den Wert falsch ergibt und der Zählimpulszähler noch auf weitere Zählimpulse wartet. Erst wenn er hundert beisammenhat, dann beginnt eine Auswertung. Für einen Auswertung wird erst einmal das Interrupt-Handling abgeschaltet, damit die Warteschlange für Interrupts nicht überläuft. Dann holt er sich mit millis() die aktuelle Prozessorzeit und berechnet die Zeitdifferenz zur letzten Auswertung, wobei er sich am Ende von loop() die Prozessorzeit als alte Zeit gemerkt hat. Aus der Anzahl 100 an Zählimpulsen, für die er das Zeitintervall vermessen hat, und dieser Zeitdifferenz dafür, berechnet er nun die Zählrate als Kommazahl. Diese Zählrate schreibt er aufs Display, wobei er dort alte Daten vorher durch Leerzeichen ersetzt um die Zeile zu löschen. Dann merkt er sich die Prozessorzeit als alte Zeit und setzt den Impulszähler auf 0 zurück für die nächste Auswertung in einem erneuten Schleifendurchlauf der loop()-Routine.

Danach erfolgt die Ausgabe von Datum und Zeit aus der Real-Time Clock und der Zählrate auf die SD-Karte und optional auf den Serial Monitor. Zum Schluss wird das Interrupt-Handling wieder scharf geschaltet und alles beginnt von neuem.

Insgesamt ist das also ein sehr überschaubarer Code, wenn man das einmal verstanden hat. Und damit liegt nun auch alles offen und keiner kann mehr ein Patent draus machen oder einen Gebrauchsmusterschutz drüberlegen 

[NuclearPhoenix]

Ist doch gut, jetzt noch ein GSM/WLAN Modul und schon kann man das Ding in irgendein Messnetz integrieren

Wie viele Impulse/s kann der alte AVR Chip eigentlich verarbeiten? Bis zu 10000imp/s gibt das Zählrohr laut Datenblatt ja relativ linear her. Ist natürlich kein wirklich realistisches Szenario für die allermeisten Anwendungsfälle hier, aber warum nicht ausnutzen, wenn man es kann. Ich denke mal bei der Rate geht der Arduino schon ziemlich in die Knie.

Was war eigentlich letztendlich der Plan? Ein Gerät entwickeln, was man aus vielen konventionellen, schon fertigen Teilen "einfach" zusammenbauen kann oder willst du die ganzen Shields dann schon auf einer eigenen Platine integrieren? So wie ich das raushöre soll das dann schon ein fertiges, komplett integriertes Gerät werden.

[DL8BCN]

Wir hatten ja gelernt, das ,,max.countrate" auch durch die GA-500 Schaltung limitiert werden könnte.

[NuclearPhoenix]

Ja richtig, ich finde aber man sollte das trotzdem ausreichend dimensionieren. Vielleicht wechselt man ja irgendwann mal das GA-500 aus welchen Gründen auch immer und dann bleibt man am Mikrocontroller hängen. Oder bleibt es fix dabei? Dann ist es natürlich egal.

[opengeiger.de]

Ich habe gerade ein super-hilfreiche Veröffentichung vom BfS und der PTB zu den ODL-Sonden gefunden  . Sie ist im Jahr 2020 in der renommierten Zeitschrift "Radiation Protection Dosimetry" erschienen und heisst "The German dose rate monitoring network and implemented data harmonization techniques" (Autoren: U.Stöhlker et al.). Da steht Einiges zu den GS07 und GS08 Sonden drin, die offensichtlich zwar vom BfS entwickelt, aber bei VacuTec und Saphymo (heute Bertin) hergestellt werden. So eine Sonde kostet also 4500 Euro mit allem  .

Was aber mega-interessant ist, ist die Beschreibung wie die Sonde charakterisiert und kalibriert wird. Man muss sich da natürlich dann irgendwann die Frage stellen, muss das alles so sein, und vor allem was kostet das den Steuerzahler? Vielleicht haben die einfach auch nur Spaß daran, bis an die Grenzen der Genauigkeit zu gehen, wenn wir das bezahlen? 

Ich muss das Paper aber morgen noch mal ganz in Ruhe lesen. 

Man bekommt es unter anderem hier:
https://academic.oup.com/rpd/article-pdf/183/4/405/28882512/ncy154.pdf

(Radiation Protection Dosimetry (2019), Vol. 183, No. 4, pp. 405–417,    DOI: 10.1093/rpd/ncy154)

[opengeiger.de]

Ich habe nun das Paper des BfS und der PTB über die ODL-Sonden des BfS sorgfältig gelesen. Ich muss sagen, das gewährt schon sehr tiefe Einblicke, was die Herrschaften da so treiben. Man bekommt insbesondere durch den Hinweis auf die Ausstattung zukünftiger Sonden mit LaBr3 Detektoren und das zitierte Paper von Bossew (/10/ Estimating the terrestrial gamma dose rate by decomposition of the ambient dose equivalent rate) schon den Eindruck, dass der staatliche Auftrag ein ODL-Netzwerk zum Katastrophenschutz zu betreiben schon auch etwas dazu benutzt wird um ,,cutting edge" Forschung mit modernster Technologie zu betreiben, die auch etwas über das Notwendigste hinausgehen darf um dann auch international veröffentlichen zu können. Aber das Gute daran ist, wenn die Ergebnisse, wie hier, frei zugänglich veröffentlicht werden, dann kann man die BfS/PTB Ergebnisse auch als Citizen Scientist noch verwerten. Und das tun wir doch gerne. 

Also was kann man Wichtiges aus dem Paper rausziehen:
Das Zählrohr der neueren Sonden ist nicht das 70031E sondern das 70031A, welches auf H*(10) energiekompensiert ist.

Die PTB macht aber offensichtlich ihre eigenen Specs und überschreibt damit das, was der Hersteller in seinem Datenblatt stehen hat. Dazu betreibt das BfS zusammen mit der PTB eine irre aufwändige Charakterisierung des Zählrohrs, mit allem, was da heut so die Grenze der Möglichkeiten darstellt. Damit wird das 70031A zum bestcharakterisierten Zählrohr ever  . Wir bekommen also den mittleren Konversionswert Zahlrate pro uSv/h und Nullrate aus einer langjährigen Charakterisierung durch die PTB. 

Der mittlere Konversionsfaktor für das 70031A ab 2015 ist laut PTB 968cpm/(uSv/h) oder 16.1333cps/(uSv/h) also etwas mehr als im VacuTec Datasheet.

Die mittlere Nullrate beträgt 16cpm/(uSv/h) oder 0.2667cps/(uSv/h).

Die Energy Response wird auf interessante Weise angegeben. Zwischen 60 und 660keV ist die Abweichung von der ideal flachen Kurve < 10% und zwischen 60 und 1300keV ist sie < 1300keV. Und darüber ???

Die kosmische Strahlung wird berechnet und nicht gemessen. Die Berechnung erfolgt nach Formel (1) und wird nur abhängig von der Meereshöhe angegeben, eine Abhängigkeit von Lat./Lon. gibt es nicht.

Ich denke, das ist nun das Wichtigste für alle die ein 70031A besitzen und genaue Messungen machen wollen. Der Rest des Papers ist aber trotzdem noch lesenswert!

Edited: Die Totzeit ist  mit 3*10E-6 min angegeben! Also in Mikrominuten! Das sind 180us und das passt!!! 

[NoLi]

...
Man bekommt es unter anderem hier:
https://academic.oup.com/rpd/article-pdf/183/4/405/28882512/ncy154.pdf

(Radiation Protection Dosimetry (2019), Vol. 183, No. 4, pp. 405–417,    DOI: 10.1093/rpd/ncy154)

Ein guter und vor allem im Gegensatz der meisten allgemeinen Veröffentlichungen relativ aktueller Artikel, welcher das IMIS des BfS mit mehr Details beschreibt, um die Eigenschaften der Messsonden kennen zu lernen.
Er zeigt aber auch die Unschärfen des Eigen-Nulleffektes sowie die Bandbreite des Kalibrierfaktors (Fig. 1 + Fig.2 , Seite 408) der früheren Zählrohre, also aus der selbstständigen VacuTec-Zeit, als dieser Hersteller noch nicht zur Hörmann-Gruppe gehörte, auf, im Vergleich zu den Zählrohren in der seit dem Jahr 2015 aktuellen GS07/08-Sonde. Kein Wunder, dass das BfS alle 2150 Zählrohre ihres IMIS getauscht hat, obwohl ihr Lebensdauerende noch nicht erreicht ist, und diese getauschten Zählrohre 70031A auf dem freien Markt zu günstigen Konditionen erhältlich sind.

Norbert

[Flipflop]

Man bekommt es unter anderem hier:
https://academic.oup.com/rpd/article-pdf/183/4/405/28882512/ncy154.

Über diese Seite habe ich noch das hier gefunden, finde ich auch interessant:

Kalibration von Strahlungsmessgeräten Radioaktivitäts-Messer im Untergrundlabor - 30
Jahre UDO

https://www.laborpraxis.vogel.de/radioaktivitaets-messer-im-untergrundlabor-30-jahre-udo-a-aa3ee0a05894f9963b1dfdb89686d191/