GeigerLog & RadPro an FNIRSI GC-01

[DG0MG]

Also hat man einen schnellen Timer, den man rasend schnell auslesen kann, und einen Offset, der beim booten bestimmt wurde, und mit dem man aus dem Timer die Uhrzeit bestimmt.

Achso, das ist aber etwas anderes - so ergibt das Sinn. Also die (hardwaremäßige) Echtzeituhr läuft weiterhin mit 32 kHz, wird nur einmalig beim Einschalten abgefragt. Zusätzlich läuft ab Einschalten eine "andere" Uhr im Prozessor, deren Takt jetzt vom 8 Mhz-Quarz abgeleitet wird (sowas wie "Sekunden seit Einschalten"). Die aktuelle Zeit ergibt sich aus der Summe des Einschaltzeitpunktes plus der inzwischen vergangenen Sekunden. Wenn dieser 8-MHz-Quarz "schlechter" ist, läuft die Uhr also im eingeschaltenen Zustand ungenauer, als im ausgeschaltenen Zustand.
Ist es eigentlich dann "good practice" beim Ausschalten die 32-kHz-Uhr wieder mit der neuen Uhrzeit zu stellen oder lässt man das besser bleiben?
Weil: Die beiden Uhrzeiten laufen ja definitv auseinander - wie weit, ist nur davon abhängig, wie lange das Gerät dauerhaft eingeschalten bleibt. Je nach Richtung des Auseinanderlaufens könnten sich ja dann auch wieder die von @ullix beschriebenen Zeitsprünge ergeben.

[ullix]

Das wird ja noch richtig elektronisch spannend :-)

Das "Y2" Bauteil ist in meinem GC-01 leicht goldfarbig, und hat die Aufschrift "DA012C" (die "0" ist auch schmal wie Null, und nicht breit wie Otto). Komisch, Google kennt die Beschriftung für alles mögliche, aber nicht für Elektro-Zeugs. Gibt es ein Datenblatt? Das "8.000" Dingens heisst bei mir nur "Y". Aber die beiden Cap neben beiden sind schon verräterisch (wenn man erstmal darauf aufmerksam gemacht wird). 

Ich finde den ARM M3 interessant, und hab mir ein Blue-Pill board zugelegt. Dies hat neben dem "8.000" noch ein "32.768K E C G7", was ein MC-306 (kHz Frequency Range Crystal Unit Surface Mount (SMD)) zu sein scheint. Zur Genauigkeit finde ich: ±20-±50ppm, sowie 1.0µW Max..
 
Also auch hier zwei Oszillatoren. Die umgeschaltet werden, je nachdem wo der Strom herkommt? Hmmm. Ich habe zwangsläufig mit USB-Strom gemessen. Man müßte also den Chip 1 Woche liegen lassen, um dann die Clock Drift zu messen?

Nun gibt es von STM die AN2604 Application note (STM32F101xx and STM32F103xx RTC calibration), worin erklärt wird, wie die 32.768 kHz (nicht die 8.000MHz) korrigiert werden können, um eine höhere Genauigkeit zu erreichen. Mit meinen 50ppm habe ich zwar ungefähr richtig gelegen, aber den falschen Quartz beschuldigt :-(.

In dem AN2604 heisst es aber auch: The STM32F10xxx RTC digital clock calibration feature allows the user to adjust the clock accuracy during manufacturing (or later)!!!. Also, wenn Gissio sich der Sache annimmt, könnte man die Clock Drift deutlich verbessern!

[ullix]

" rasend schnell auslesen " ist ja ein sehr dehnbarer Begriff. Ich nutze z.B. auf einem ESP32 eine DS3231 RTC, die über I2C ausgelesen wird. Und diese Auslesedauer ist im wesentlichen durch I2C bestimmt, und auch die war so schnell, dass sie mich nicht störte in einer Anwendung ähnlich wie in RadPro. Warum sollte die im STM32 direkt im Chip eingebundene RTC langsam oder gar extrem langsam sein?

Die Zeit, die GeigerLog benötigt, um den timestamp vom GC-01 auszulesen scheint mir im wesentlichen durch die serielle Leitung bestimmt zu sein.

[ullix]

Die Lichtempfindlichkeit der J321 Röhre in meinem GC-01 ist extrem! Ich habe die Rückseite des GC-01 abgeschraubt, und das gerät mit der Röhre nach-oben-zeigend in eine Black-Box gelegt. Ich glaube, man kann aus den CPM-Daten gut erkennen, wann die Box offen, und wann geschlossen war.

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

Extra Punkte gibt es, wenn man aus dem Zeitpunkt des Sonnenuntergangs den Breitengrad meines Wohnortes berechnen kann ;-)

Das Gehäuse des GC-01 ist ja recht stabil, und weitgehend lichtdicht. Aber solch ein solides Gehäuse führt auch zu einer verringerten Beta Empfindlichkeit. Öffnet man aber das Gehäuse um seine Probe an die nackte Röhre zu bringen, misst man möglicherweise im wesentlichen Licht und nicht Radioaktivität. Gehäuse von GQ's GMC Countern sind transparenter, was aber bei diesen zu reichlich Licht-Problemen geführt hat.

Die Licht-Empfindlichkeit von Glas-Geiger Röhren ist bereits vor 7 Jahrzehnten beschrieben worden, sogar von deutschen Forschern. Eine Übersicht ist in dem GeigerLog Manual, Chapter Appendix H – Light Sensitivity of Glass Geiger Tubes.

Deren Erklärungen leuchten ein. Unverständlich für mich ist, warum es dann Glasröhren gibt, die NICHT lichtempfindlich sind; ich hab einige von diesen.

Schade dass die SBM20 nicht mehr hergestellt wird.

[DG0MG]

Der Engländer in China hat zur Lichtempfindlichkeit von Zählrohren zu einem Experiment aufgerufen:

[ullix]

Der Video-Typ ist nicht nur kompetent, der kann auch Didaktik und Medien! Sehr empfohlen.

Jedoch: 100 MOhm am DVM reichen nicht; es sollten schon 1 GOhm sein. Auch bei 100M bricht bei den meisten Countern die Anodenspannung zu stark ein.

Bei meinem GC-01 messe ich eine Spannung Anode-Kathode von 650V. Das ist knackig, und vieeeel zu hoch! Kann man das irgendwo verstellen - ich finde nichts "drehbares" auf dem Board? Oder wird das über die Firmware eingestellt?

Allerdings, ich glaube, seine Schlussfolgerungen sind in dieser Beziehung falsch. Ich habe ca. ein Dutzend M4011 Röhren in einem GMC-300E+ Counter getestet. Dadurch haben alle dieselbe Spannung gesehen. Dennoch waren einige Licht-Empfindlich, andere hingegen überhaupt nicht!

Übrigens ist UV Licht nicht notwendig. Ich habe LED 395nm, LED 365nm getestet, aber die stärkste Wirkung habe ich mit einem 405nm Laser gesehen. Dass ist deutlich hell-blau; definitiv nicht im UV Bereich. Hab ich sogar im Video gezeigt; an der Kathode gibt es die Action. https://www.youtube.com/watch?v=l3Kw6xb5Nl0

Mich interessiert das Spectrometer sehr. Der Link auf eine rein chinesische Webseite ist aber nicht hilfreich. Kennt jemand eine andere Quelle?

[Elektroniknerd]

Ist es eigentlich dann "good practice" beim Ausschalten die 32-kHz-Uhr wieder mit der neuen Uhrzeit zu stellen oder lässt man das besser bleiben?

In "meinen" Geräten (Industrieelektronik) habe ich da keine Wahl: da ist der Strom sehr plötzlich weg und "beim Ausschalten" ist zu spät, um noch groß was zu machen.

Beim Linux wird die Hardware-Uhr ebenfalls nur beschrieben, wenn man das explizit angibt.

Bei neueren Systemen ist es einfach, die Hardware-Uhr recht genau (5ppm) zu machen, das ist kaum teurer als veraltete ICs zu nehmen, die man schon vor 20 Jahren verbaut hat. (Zumindest für 1000er Stückzahlen vom seriösen Distributor. China-Clone uralter Dallas-ICs mit 20ppm mögen da deutlich billiger sein. )
Insofern würde ich da eher die Systemuhr gelegentlich nach der Hardware-Uhr stellen, wenn es keine bessere (Netzwerk)Zeit gibt *und* das gegeneinander weg laufen ein Problem ist.

Die umgeschaltet werden, je nachdem wo der Strom herkommt?

Es gibt verschiedene Clock und Power-Sektionen. Die Uhr und der Uhr-Oszillator sind die Low-Power-Sektion, die (auch) aus der Batterie versorgt werden können, die laufen damit "immer" durch.
Der 8MHz-Bereich, aus dem letztlich alle "schnellen" Takte erzeugt werden und an dem die CPU, die (meisten) Timer und überhaupt fast alles hängt, läuft nur mit der "dicken" Spannungsversorgung und geht aus, wenn der Akku (oder die "große" Batterie) fehlt oder das System ins Standby geht.
Die "Umschaltung" erfolgt hier nicht am Takt, sondern letztlich dadurch, was das Programm verwendet bzw. ausliest. Die Uhr hängt immer am 32kHz Takt, die schnellen Systemtimer immer am 8MHz Takt bzw. an dem daraus per PLL gewonnenen Systemtakt.

Wenn das System im Betrieb eine Softwareuhr (Timer, aus 8MHz) und im Standby die Hardware-Uhr nimmt, dann muss man die beide tatsächlich getrennt betrachten.
In Anbetracht des Aufwandes sollte man überlegen, was man damit erreichen möchte: wenn der zu erwartende Fehler absehbar stören wird, dann kann man auch gleich anfangen, an der Lösung zu arbeiten.
Erwartbarer Fehler: 25ppm Uhrenquarz, 50ppm Hauptquarz. Beide haben völlig unterschiedliche Temperaturfehler, der Uhrenquarz hat nochmal -25ppm, wenn er von 0...50° laufen muss, der 8MHz Quarz kann viel besser sein, muss er aber nicht (Zufall/Qualität).
Unter Laborbedingungen (ziemlich konstante Temperatur) kann man den Fehler auf 5ppm bekommen. Unter Laborbedingungen hat man aber auch Netzwerk und kann die Netzwerkzeit nutzen, da ist es vermutlich sinnvoller, den Aufwand in die Zeitsynchronisierung zu stecken.
Unter Feldbedingungen ist der Softwareabgleich der Uhr eher verlorene Mühe, denn das halbiert den (unter moderat pessimistischen Bedingungen zu erwartenden) Fehler grade mal.
Da muss dann entweder eine bessere Hardware-Uhr her (5ppm kann man günstig kaufen und per I²C an die CPU frickeln) oder man bastelt GPS, DCF77 (... eher theoretisch) oder Händie(...Netzwerk) dran.

" rasend schnell auslesen " ist ja ein sehr dehnbarer Begriff.

Ja klar.
Wenn man hier nur die Klicks per Interrupt zählt und dann eine Hauptschleife hat, die das mittelt und mit (Uhr-)Zeitstempel versehen seriell ausgibt, dann geht das super.

Wenn man aber ein System hat, bei dem man im Zweifel auch mal Interrupts mit 2µs Latenz mit einem Echtzeit-Uhrstempel versehen will, dann kann man da keinen System-Aufruf gebrauchen, der - je nach Umgebung - auch mal über eine I²C Bibliothek 10Bytes mit 400kHz Takt (macht ein paar hundert µs) aus der Hardware-Uhr liest.

Und außerdem hängt das auch noch von der CPU ab. Betagte 80er Jahre CPU (8051...68000)? Kleiner Arduino mit ATMEGA? Der STM32 hier? Ein ESP32? Raspi?
Und von den verwendeten Bibliotheken. Hardcore Echtzeitfähig oder Warteschleife mit abgeschalteten Interrupts?
Die "Last" durch mehr oder weniger umständliche Bibliotheken "verkraften" schnellere CPUs immer besser.


Deswegen deeeehnbaaaaar.

In dem Fall hier geht sicher beides.

Der Punkt ist einfach nur gewesen, dass man damit rechnen muss, dass die Uhrzeit nicht immer nur aus dem Uhrenquarz kommen muss.

[DG0MG]

Bei meinem GC-01 messe ich eine Spannung Anode-Kathode von 650V. Das ist knackig, und vieeeel zu hoch! Kann man das irgendwo verstellen - ich finde nichts "drehbares" auf dem Board? Oder wird das über die Firmware eingestellt?

Ich hab jetzt keinen GC-01, aber einen FS2011 und einen FS-600 (beides chinesische Krücken aus dem Billigsegment). Bei beiden ist die Hochspannungserzeugung so gelöst, dass es einen Transistor mit Induktivität Richtung Betriebsspannung, dahinter eine Vervielfacherkaskade gibt. Am Ausgang der Kaskade kommt der Anodenwiderstand des Zählrohres und dann das Zählrohr. Die Stabilisierung auf z.B. 400 Volt wird bei beiden Geräten so gemacht, dass parallel zum Zählrohr eine Z-Diode liegt (z.B. 2x 200 Volt in Reihe), die die Zählrohrspannung auf 400 Volt "klemmt". Das ist natürlich eher die "russische" Methode und STand der Technik der 60er Jahre, als man die Zählrohrspannung mit Glimmstabilisatoren über deren Brennspannung konstant gehalten hat. Es gibt keinen geschlossenen Regelkreis, damit ist die Stromaufnahme der HV-Erzeugung unnötig hoch.

Wenn man sich da Bild nochmal anschaut: https://raw.githubusercontent.com/Gissio/radpro/main/docs/devices/FNIRSI%20GC-01/img/gc-01-board-type.jpg
dann erkenne ich diese zwei Z-Dioden nicht, Du kannst ja mal danach suchen.
Entweder die haben die ganz weggelassen (was noch schlimmer wäre, da überhaupt nichts mehr die Zählrohrspannung begrenzt) oder es gibt doch eine Regelung (ich glaube nicht daran).

Wenn Du die RadPro-Software drauf hast, kannst Du unter den Zählrohrparametern die PWM-Frequenz und die Einschaltzeit für den Spulenstrom einstellen. Damit kann man die Spannung senken. Das ist aber trotzdem noch nicht der Weisheit letzter Schluss, denn die Zählrohrspannung ist damit weiterhin immer von der Batteriespannung abhängig.

[Elektroniknerd]

Hier gibt es einen Schaltplan:
Schaltplan FNIRSI GC-01

Auf der Platine sehe ich auch keine Z-Dioden, der Schaltplan scheint zur Platine zu passen, ich sehe zumindest keine Widersprüche.

Die Hochspannung wird demnach aus einer geregelten 3,3V Versorgung erzeugt, die Batteriespannung ginge damit immerhin nicht ein, dennoch ist die ungeregelte Erzeugung natürlich Murks.
Superärgerlich, die CPU hat einen integrierten AD-Wandler und es gibt mit R38 sogar schon einen "Lastwiderstand", den man nur noch aufteilen müsste, um eine verwertbare Spannung zu bekommen. Da fließen etwa 50µA, für 2V "Messspannung" am Wandler also 180kOhm in Reihe, das ist völlig praktikabel, nur für den AD zu hochohmig: also noch einen einfachen OP-Amp dazwischen bauen (20Cent, also machbar). Nur nicht mehr als nachträglicher Patch auf die Platine zu bekommen.

Es gibt 7 Stufen in der Kaskade. Bei 650 Volt wären das 93Volt pro Stufe, also kann man etwa(!) 560, 460 und 370Volt raus bekommen, indem man Stufen weg lässt.
Fix gegoogelt:
Röhre "M4011"  380-450V, recommended 380V, max. 550.
Röhre "J321" 380V recommended, max. 600V

Für die 460V Stufe: C9 auslöten und C16 überbrücken.

Irgendwo hatte ich aber gelesen, dass die Originaleinstellung der PWM ziemlich bekloppt war und man mit sinnvoller Einstellung erheblich Strom sparen kann. Also erst mal sinnvoll Einstellen, dann noch mal messen und dann passend Stufen auslöten. Weniger Stufen verbessern den Wirkungsgrad und machen das ganze stabiler.

[DG0MG]

Oh, das ist neu, den Plan hatte ich nicht gefunden.  Aber die fehlenden Klemm-Z-Dioden bedeuten, dass der GC-01 NOCH SCHLECHTER als der von mir bisher als "absolute Unterkante" betrachtete FS2011 ist! 

Drinherumlöten würde ich erstmal nicht. Vielleicht bekommen wir zusammen mit @Gissio noch eine allgemeingültige Möglichkeit hin, die mit geringer Hardwareänderung (für die natürlich auch ein Lötkolben nötig ist) eine echte Regelung bei allen unterstützten Geräten nachrüstet.

also noch einen einfachen OP-Amp dazwischen bauen (20Cent, also machbar)

Dieser Aufwand ist nicht nötig, auch wenn er natürlich extrem elegant ist. Es sollen ja soviele GZ-Besitzer wie möglich die Modifikation durchführen. Ich würde das so wie im GammaScout realisieren: NIcht die Spannung über dem Ladekondensator auswerten, sondern nach der ersten Diode über zwei Z-Dioden die Pulse auf einen Prozessoreingang zurückführen:
GammaScout und Multigeiger.


Hier hatte ich die RadPro-Parameter mal mit dem FS-600 ausgetestet: PWM-Frequenz und Duty-Cycle.
https://www.geigerzaehlerforum.de/index.php?msg=25617
Das kann man zwar nicht 1:1 auf den GC-01 übertragen, aber eine Idee, in welche Richtung die Parameter gehen, gibt die Tabelle schon. Um die Spannung zu senken, muss man die PWM-Frequenz verringern (dadurch wird die Einschaltzeit pro Zyklus erstmal sogar LÄNGER, die Stromaufnahme steigt) und dann den Duty-Cycle verringern (also die Einschaltzeit des Transistors, die Gesamtstromaufnahme und die Spannung an der Kaskade sinkt wieder).

[ullix]

Hardwareänderungen auf einem SMD Boards sollte man gar nicht erst in Betracht ziehen. Sind aber auch nicht notwendig, da über PWM & Freq die Spannung verändert werden kann. Allerdings scheinen die Einstellungen doch recht verschieden von denen des FS-600 zu sein.

Ich hab mir beim Rumspielen erstmal ein Bein gestellt: Nachdem im HV profil das Factory Default vorgewählt war, habe ich auf Custom Profile umgeschaltet, und erwartet, dass mir eben diese Defaults gezeigt werden würden. War aber nicht so. Später habe ich realisiert, dass nur die jeweils ersten Werte in den beiden P & F Listen markiert waren. Damit ging gar nichts. Kein Wunder, die Anoden-Spannung war um die 30V :-(

Mit ein bisschen Fummeln habe ich eine Einstellung gefunden, bei der es wieder clickte: PWM=11%, Freq=1.25kHz führten zu 330V. Was überraschend niedrig ist; da hätte ich keine Funktion erwartet. Aber mit ein bisschen Uran kommen die Counts, und CPS ist klar Poissonian. Scheint also ok.

Die Lichtempfindlichkeit ist nun deutlich geringer. Mit LED weiss, LED 395nm, LED 365nm so gut wie keine Reaktion. Mit Laser 405nm hingegen deutliche Reaktion, aber nur auf einem kleinen Fleck ca. 2cm von der äußeren Kathodenspitze Richtung Anode. Solch ein Punkteffekt ist ja auch bereits in meinem Youtube-link zu sehen.

Mal schauen, was der Sonnenschein macht.

 

[Elektroniknerd]

Ich habe keine Idee, wie man das mit der Regelung ohne echten Bastelspaß hin bekommt... (=> neues Topic in der Hardwarebastelsektion?)
Man braucht Bauteile UND muss an der CPU (mit 0,5mm Beinchenabstand) rum löten. Und das, wo man für 60€ ein Gerät bekommt, dessen Hardware gleich richtig funktioniert. Ich fürchte, da werden nur sehr wenig Leute mitmachen. Ärgerlich, weil es ja eigentlich gut zu machen wäre...

Drinherumlöten würde ich erstmal nicht.

... oder, um es mit Ideal zu sagen, "für den halben Luxus leg ich mich nicht krumm"... ohne Regelung bleibt es Murks, und dann kann man auch gleich nur die PWM-Werte in der Software so hin fummeln, dass die Spannung halbwegs sinnvoll ist.

Der "Mindestlastwiderstand" R38 mit 51MOhm zieht bei 650V 12µA. Den Zählrohrverbrauch kennen wir hier nicht. Bei dokumentierten Zählrohren habe ich da 20...100µA bei 10mGy/h gefunden (..und natürlich (fast) Null nur mit Hintergrundstrahlung). Die "Spannungs"-Erzeugung (mit der Sperrwandler-Topologie)hat einen sehr großen Innenwiderstand, der Vervielfacher macht das nicht besser 
Das lässt vermuten, dass die Leerlaufspannung absichtlich so hoch gewählt wurde: damit die Spannung nicht schon bei Dosisraten einbricht, die ein durchschnittlicher U-Tuber noch hin bekommt.

Was helfen könnte: die PWM anhand der aktuellen Zählrate zu steuern. Das ist allerdings hochgradig empirisch.
(SEHR unwahrscheinlich: die Originalsoftware der Kiste macht das schon, und die 650V bekommt man erst mit der RadPro-Firmware.)

[ullix]

Eine echte Regelung der Anodenspannung sehe ich nicht als großes Problem an. Könnte man den ADC benutzen, wäre das schöner, aber das ist nicht erforderlich. (Misst der ADC eigentlich irgendetwas? M.W. können mehrere Pins des STM32 als ADC benutzt werden, so dass es müßig ist zu schauen, ob diese Pins benutzt werden?)

Die größte Schwierigkeit scheint mir zu sein, eine "leistungsfähige" HV Versorgung zu machen, sprich eine mit einem geringen Innenwiderstand. Die Counter, die ich genauer angeschaut habe, hatten einen Innenwiderstand von 10...30 MOhm. Deswegen fürcht ich, könnte eine Minimierung des Stromverbrauchs zu einem Schuss ins eigene Knie werden, weil dann evtl nicht mehr die Power für eine stabile Hochspannung besteht.

Schon vor einigen Jahren habe ich das recht detailliert untersucht. Das Ergebnis ist z.B. in dem GMC Forum zu sehen. http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=5369 Ab Reply #15 geht es um HV Power und Innenwiderstand. Dieses Bild (Reply#17) gibt einen schönen Eindruck von dem Einbrechen der HV und der Konsequenz der begrtenzten Zählrate.

Gerade bei den GMC countern gab es einige Berichte von Personen, die eine Jod-131 Behandlung bekamen, und sich einen Counter kauften um das selber zu sehen. Dann aber sahen sie "Nichts" - der Counter zeigte Null an, weil die Strahlung so stark war, dass die HV zusammengebrochen ist.

Deshalb aus meiner Sicht lieber auf kräftige HV optimieren, als auf Strom sparen!

Aber, zurück zur Regelung: diese Kurve ist nicht so schwierig zu bestimmen. Man könnte sie als Regelungsprofil nutzen.

[DG0MG]

Gerade bei den GMC countern gab es einige Berichte von Personen, die eine Jod-131 Behandlung bekamen, und sich einen Counter kauften um das selber zu sehen. Dann aber sahen sie "Nichts" - der Counter zeigte Null an, weil die Strahlung so stark war, dass die HV zusammengebrochen ist.

Das muss nicht an der HV gelegen haben - wenn das ZR in der Sättigung ist (also quasi ständig leitend) dann ist das auch so. Deshalb hat @Gissio jetzt in RadPro eine Warnung eingebaut: Wenn längere Zeit kein Tick kommt, gibts ebenfalls einen Alarm. Es könnte entweder sein, dass das ZR oder die
HV kaputt ist oder eben so ein starkes Strahlungsfeld, dass keine Impulse mehr kommen. Könnte beides ungesund werden, deshalb die Warnung.

... oder, um es mit Ideal zu sagen, "für den halben Luxus leg ich mich nicht krumm"... ohne Regelung bleibt es Murks, und dann kann man auch gleich nur die PWM-Werte in der Software so hin fummeln, dass die Spannung halbwegs sinnvoll ist.

Richtig, so sehe ich das auch. Wenn man schon den Lötkolben ansetzen will, muss es eine Regelung werden. Und es muss natürlich auch weiterhin für alle funktionieren, die die Hardware unverändert lassen.

Der "Mindestlastwiderstand" R38 mit 51MOhm zieht bei 650V 12µA. Den Zählrohrverbrauch kennen wir hier nicht.

Diesen Lastwiderstand gibt es bei den anderen beiden Geräte dafür nicht. Die haben ja die Z-Dioden.
Für ein SBM-20-Zählrohr sind glaube ich 18 oder 20 µA Maximalstrom angegeben. Da braucht man aber nicht weiter drüber nachdenken, wenn man einfach sagt: Bei einem Kurzschluss des Zählrohres muss vor dem Anodenwiderstand immer noch die HV vorhanden sein. Das sind bei 400 Volt und 5 MOhm 80 µA. Das hinzubekommen ist keine Zauberei, das kann auch der Theremino-Geiger-Adapter GA500 - und ohne Last zieht der nur einige 10 µA, was ja eher der Normalfall sein dürfte.


Ich würde mir eine einfache Lösung etwa so vorstellen:

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

Die unterste ZD könnte natürlich 3V3 sein, die beiden 200V-ZD bestimmen die Spannung. Die 20M können auch 30M werden. Der Eingang an den Prozessor muss kein A/D-Wandler sein, Digital-I/O reicht. Wenn dort High-Pegel ist, wird die PWM-Frequenz veringert, wenn Low, dann die PWM-Frequenz erhöht. Innerhalb sinnvoller Eckgrenzen natürlich.

[ullix]

Nachdem ich gestern die HV an meinem GC-01 auf 330V eingestellt hatte, habe ich eine neue "Sonnenscheinmessung" gemacht wie oben beschrieben. Mich wunderte, dass die Lichtempfindlichkeit genau so hoch schien, wie mit der höheren Spannung. Die über-Nacht Messung bestätigte: eigentlich kein Unterschied.

Heute morgen hab ich noch schnell die HV Messung gemacht: 650V ! Nanu, das sollten doch 330V sein?

Ist da eventuall schon eine Regelung aktiv? Frage an @Gissio