Zitat von: Tomas am 23. Mai 2025, 18:28da HV Schaltung durch 3.3V LDO versorgt wird.

Ok, da hast Du recht. Wahrscheinlich ist das der Grund, warum das Gerät überhaupt so halbwegs funktioniert.

Aber die wertvolle Batteriespannung längsgeregelt herunterzustabilisieren, um sie danach hochzutransformieren, erscheint mir auch nicht sehr sinnvoll. Wenn die Batterie vollgeladen ist, muss der LDO 0,9 V verbraten, bei einem durchschnittlichen Spulenstrom von angenommenen 20mA sind das 18mW die dauerhaft in Wärme umgesetzt werden. Das erscheint nicht viel, aber man überlege mal, wie hell eine moderne weiße LED mit Uf 3,3V bei 5,5 mA (sind auch 18mW) schon leuchtet, da kann man damit gut im Dunklen lesen!

Zitat von: DG0MG am 23. Mai 2025, 20:16bei einem durchschnittlichen Spulenstrom von angenommenen 20mA sind das 18mW die dauerhaft in Wärme

Wenn PWM duty cycle 50% ist, dann es ist nur 9mW. 

HV Schaltung von FS5000 gefällt  mir besser, aber GC-01 hat bessere 5Tasten Bedienung. 

P.S. Wer sagt dass Spulenstrom 20mA ist? Haben Sie das gemessen?

Zitat von: DG0MG am 23. Mai 2025, 20:16angenommenen 20mA

nein, ich habe es geschätzt. Es geht auch nicht darum, ober der Wert nun stimmt oder nicht, sondern um das Grundprinzip einer möglichst stromsparenden, energieffizienten Schaltung, zu der eine vorhandene Regelung ein wichtiger Schritt ist.
Vor mittlerweile fast 25 Jahren hat der Konstrukteur des GammaScout die völlig einfache Schaltungsanordnung patentiert, die das Gerät ~10 Jahre! dauerhaft laufen lässt. Da müssen wir uns jetzt hier mit Geräten befassen, die Stunden laufen und freuen uns schon, wenn mal eins 2 Wochen durchhält.

Zitat von: DL3HRT am 23. Mai 2025, 10:50Ich kenne einige HV-Schaltungen, die zumindest mit einem 10 MOhm-Multimeter keinen Einbruch der Spannung zeigen. An unserem AATiS-Geigerzähler konnte ich nach dem Austausch der 1N4007 Dioden gegen UF4007 einen 10 MOhm Lastwiderstand anschließen und parallel dazu mit dem Multimeter messen, ohne dass die Spannung eingebrochen ist. Das sind immerhin 80 µA und war noch nicht die Grenze. Da braucht es bei normalen Zählrohren schon eine sehr hohe Aktivität, um diesen Strom zu erreichen.

Hast Due einen Link dafür?

Wenn das so gut geht, warum wird es nicht weltweit benutzt? Wo ist der Haken?

Zitat von: ullix am 23. Mai 2025, 08:46Die Korrektur-Faktoren sind empirisch bestimmt; sie finden sich in meinem GeigerLog code, der ja Open Source und daher einsehbar ist. Man kann sie aber auch de-novo bestimmen; ist letztlich recht einfach.

Kannst du File Name sagen, wo ich dieses Code finden kann?

Zitat von: Tomas am 24. Mai 2025, 11:38Kannst du File Name sagen, wo ich dieses Code finden kann?

gdev_radpro.py

Ein paar höchst kuriose Ergebnisse zu RadPro auf FNIRSI GC-01!

Ich habe 2 Geräte mit demselben Namen FNIRSI-GC-01, jedoch mit verschiedenen Innereien:
#1 - blaues Gehäuse - FNIRSI GC-01 (APM32F103CB) Chip:GEEHY; mit  Rad Pro 2.0.2
#2 - gelbes Gehäuse - FNIRSI GC-01 (CH32F103C8)  Chip:WCH;   mit  Rad Pro 2.0.3
Diese verhalten sich teilweise drastisch verschieden, was z.B. die Settings für die Anodenspannung angeht. GeigerLog erkennt die Unterschiede, und macht korrekte Settings. Beide Geräte funktionieren mit RadPro und GeigerLog.

Das Auslesen der Counts geht mit dem Kommando: GET tubePulseCount. Dies antwortet mit einen String <Unix-Timestamp mit sec Auflösung> , <Cumulative Counts> ; ähnlich wie: 1786306123,12975320;.

Daraus macht GeigerLog CPS Werte, und daraus CPM Werte. Letztere z.B. in Bild1 (oben) als Zeit-Kurve in braun zu sehen. Ein Poisson-Check dieser Daten (Bild1 unten-links) bestätigt "Daten OK".
Sie dürfen in diesem Board keine Dateianhänge sehen.

Nun hat RadPro auch den Befehl GET tubeRate, der direkt den aktuellen CPM Wert liefert, wie z.B. 223.639. Dieser Wert wird dem User im Display angezeigt, evtl. umgerechnet in andere Units (CPS, Sv, REM).

Dieser Wert ist in Bild1 in Cyan dargestellt. Man sieht sofort 2 Dinge an diesen RadPro-CPM Daten: 1) die Werte fluktuieren erheblich stärker als die GeigerLog Werte, 2) mehr Werte sind größer als die GeigerLog Werte (Cyan Fläche oben ist größer als unten).

Das hat zur Folge, dass der Poisson Test völlig versagt (Bild1-unten rechts), und das auch die Mittelwerte verschieden sind: GeigerLog: CPM=232, RadPro:CPM=253, also +9%! Wohlgemerkt, basierend auf den EXAKT selben Daten!
 
Der User wird sich wundern über die ungewöhnlich heftigen Schwankungen in der Anzeige. Das erinnert an die von den Usern bemängelten Schwankungen bei den GQ Countern verursacht durch die FET Einstellung (wird abgeschaltet mit FET=60). Welcher Algorithmus bei RadPro dafür verantwortlich ist, ist mir nicht bekannt. Abschaltbar scheint er nicht zu sein.

Liegt's an GeigerLog? Der GC-01 kann ja auch die History speichern; also lasse ich 1x pro sec speichern. GeigerLog kann das auslesen. Ergebnis gezeigt in Bild2. Poisson Check bestätigt: Time course ist auch hier ok. Den Mittelwert von CPM=225 nenne ich identisch zu den CPM=232 aus Bild1 angesichts der 4.5x geringeren Counts.

Die hohen Fluktuationen sind also ein RadPro Effekt, kein GeigerLog Effekt!

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

Mein zweites GC-01 hat andere Hardware und etwas neuere Firmware. Im gleichen Setup ergibt sich Bild3 (oben). Vom Anfang bis Minute 18 sieht man dasselbe Verhalten: viel höhere Fluktuationen bei RadPro als bei GeigerLog. Dann aber crasht RadPro - jeder zweite Wert is um ca 30 Mio (!) höher als der (vermutliche) Normalwert! Mit somit 30 Mio bins kann GeigerLog kein Histogram mehr bauen; ein Poisson-Check ist unmöglich (und offensichtlich sinnlos).

Die History (siehe Bild3-unten) wird aber korrekt gespeichert, denn der Bereich 18-24 min in der History ist ungestört.

Das sieht eher einfach aus, nur ein neuer Bug in dieser jüngeren Firmware.

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