RadPro ist m.E. eine großartige Leistung, und mit Gissios Vorarbeit war die Integration in GeigerLog nicht allzu problematisch. Ich habe viel getestet, und hier sind erste Ergebnisse.

Mein Gerät ist ein FNIRSI GC-01 (CH32F103C8) mit J321-2022 Röhre. Installation gelang auf Windows, aber nicht auf Linux. Dieses Gerät habe ich zusammen mit einem GMC-300E+ counter (Röhre M4011) in eine lichtdichte Box gelegt - die Röhre des GC-01 ist stark lichtempfindlich! - und über Nacht den Background gemessen.

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

Gezeigt sind CPM vom GMC-300E+ (hellblau) und vom GC-01 (braun). Beide Datenreihen werte ich als excellent!

Die Unterschiede sind erstaunlich gering, angesichts möglichen Einflusses von Röhre, Anoden-Spannung, Gehäusedicke (der GC-01 ist ziemlich massiv), elektronischem Pulse Diskriminator, und anderes. Eine Kalibrierung gibt es ohnehin für beide nicht.

Beide CPM Reihen erfüllen bestens den Poisson Test! Allerdings: der GMC counter liefert sowohl CPS wie CPM "von Haus aus". Der GC-01 hingegen liefert CPS als cumulatives Signal, und CPM nur als defektes Signal, siehe hier, und hier. Da bleibt noch was zu tun!

In meinem Beispiel ist CPM für den CG-01 von GeigerLog erzeugt wurden durch Aufsummation der jeweils letzten 60 CPS Werte.

Ich bin interessiert die Erfahrung anderer mit GeigerLog & RadPro zu hören, sowohl mit demselben RadPro Device, als auch mit allen anderen. Ich habe derzeit nur dies eine Gerät.

Der letzte GeigerLog pre-Release 77 (https://sourceforge.net/p/geigerlog/discussion/devel/ ) ist voreingestellt auf RadPro (und nur RadPro). Download, GeigerLog setup machen, und dann nur einstecken und loggen. Sollte sofort funktionieren :-/

Ja, die gleichen Ergebnisse (CPS) hatte ich auch mit dem Bosean FS-600. Großartige Firmware von Gissio. Derzeit haben wir noch ein USB Problem aber ich teste da eh mit um es zu beheben.

Und.. GeigerLog ist ebenfalls großartig!

Ich habe mir jetzt die Geschwindigkeit der seriellen Schnittstelle angeschaut. Dabei hat GeigerLog im 1 sec Takt nur den Command "GET tubePulseCount" ausgeführt, und ich habe die Zeiten für Open, Write, Read, Close, und Total registriert. Da insgesamt nichts Auffälliges ist in der Graphic nur Total (unter der Variablen Xtra, in millisec, rechte Skala) gezeigt. Durchschnittlich also <4 ms, gleichmäßig unter 8 ms, mit gelgentlichen Ausreissern hier bis zum Max von 10.8 ms! Das ist überraschend schnell und gleichmäßig! Ich staune, dass der einfache micro-chip das zuwege bringt.

Die GMC counter schaffen schaffen es auch in <5 ms, aber haben regelmäßig recht lange Perioden von bis zu 150 ms, was das Timing mühselig macht.

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

Ich hab mir jetzt die History-Speicherung und Download angesehen, und das Ergebnis ist leider weite weniger erfreulich!

Der Download der History benötigt etwas weniger als 3.5 sec (was schnell ist, im Vergleich zu e.g. GMC Countern!). GeigerLog habe ich auf einen Zyklus von 4 sec eingestellt, in dem zuerst CPS (Farbe Orange) bestimmt wird durch den RadPro Befehl 'GET tubePulseCount' (schnell, nur wenige ms), und dann  der Download gemacht wird. Die Länge des Downloads in Records wird in GeigerLog als Variable Temp (Farbe rot) gespeichert. Das Ganze lief über gut 2 Tage.

Das Ergebnis zeigt die Abbildung.

CPS konnte zu jedem Zeitpunkt korrekt gelesen werden; der Counter hing nie in einer "infinite loop"! Poisson bringt natürlich Nichts, da hier ein Counts-pro-4sec Wert auf CPS umgerechnet wurde.

Es gab jedoch diverse Probleme mit dem Download. Bei der eingestellten Speicherung von Minutenwerten sollte die Rekordanzahl jede Minute um 1 zunehmen, also die rote Kurve einen "Slope 1/min" haben, wie an einem Teilstück beschriftet. Dann sollte sie ein für jeden Counter & Firmware spezifischen Maximalwert erreichen, dann - so meine Erwartung - wird ein Flash Bereich von N pages mit den ältesten Records gelöscht, und die Speicherung geht weiter. Das sind die Sprünge von 3000+ runter auf 2000+.

Das Verwunderliche zunächst einmal ist, dass alle Max-Werte verschieden sind. Und dass sie deutlich kleiner sind als die 5060 data points, die gemäß Docs vom GC-01 gespeichert werden können? Die Sprünge lagen im Bereich von 325, ..., 924 - sollten die nicht gleich sein? Und, timestamps und cumulative counts werden wohl als 32bit Wert, also 8 Byte, gespeichert. Sollten daher diese Sprünge nicht mindestens ein Vielfaches von 8 sein?

Weiter sieht man Stellen, wo die rote Kurve horizontal verläuft. Dann war zwar ein Download möglich, aber der veränderte sich nicht; der Counter hat keine neuen Werte gespeichert. Das konnte manchmal durch Unplug/Replug gelöst werden, aber an anderen Stellen (die vertikalen, bis unter 2000 gehenden roten Striche) half nur ein Cold-Boot. Und auch der musste teilweise mehrfach gemacht werden!

An wieder anderen Stellen nahm die History zwar zu, aber nur langsam mit nicht 1 pro 1min sondern von 1 pro 6 bis 15 min! Der Textauszug zeigt ein Teil des Logfile, dessen 12 konsekutive Einträge 'delta_time' von 400 bis 920 zeigen, statt 60.

Eine korrekte History scheint mir eminent wichtig zu sein, aber im Augenblick ist sie leider nicht brauchbar.

Ich teste gerne weiter in GeigerLog, sobald es Neues oder Vorschläge gibt.


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

Hi @ullix , solltest Du nicht ein issue auf https://github.com/Gissio/radpro/issues aufmachen? lg

* Rad Pro komprimiert die Daten, um die Speichernutzung zu optimieren (https://github.com/Gissio/radpro/blob/main/docs/developers.md).
* Ein Semaphor (https://de.wikipedia.org/wiki/Semaphor_(Informatik)) blockiert den Schreibzugriff auf das Datalog während des Downloads.

Ist es nicht kluger, zuerst zu fragen, und dann zu testen?

GeigerLog ist jetzt soweit für RadPro optimiert, wie es mir möglich erscheint. Auch mit RadPro 2.0rc03 auf FNIRSI GC-01 scheint alles zu laufen. Für das was jetzt nicht geht oder nicht gut genug geht bitte einen Bug Report hier: https://sourceforge.net/p/geigerlog/tickets/.

Die derzeit letzte GeigerLog Version ist pre-release pre78, hier zu finden: https://sourceforge.net/p/geigerlog/discussion/devel/

Ein Test der Clock Drift ergab, dass mein FNIRSI GC-01 (CH32F103C8) 3.5 sec pro Tag zu schnell läuft. Der 8.000 MHz Quartz dürfte wohl für die Genauigkeit verantwortlich sein. Laut Mouser gibt es die von 5 bis 50 ppm. Ein Low-cost counter wie der GC-01 dürfte wohl auch nur einen Low-cost Quartz bekommen, und 50ppm sind so ungefähr das, was ich sehe.

Nicht doll, aber auch nicht schlecht, insbesondere, da die wenigstens doppelt so teuren GMC Counter eine typische Drift von 20 sec/ day (!) haben.

Was ist denn die Erfahrung mit anderen, RadPro fähigen Countern bzgl. Clock Drift?

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

Wie errechnest Du das?
Übermittelt der GZ einfach immer die Uhrzeit und die wird mit der "echten" Zeit verglichen?


Der GC-01 hat ne Knopfzellen-Batterie drin, ich denke die Zeitbasis wird von einem extra 32-kHz-Quarz kommen? Vielelicht auch gleich im Prozessor integriert? Jedenfalls gibts soetwas im STM32G070CB, der im BOSEAN FS-600 verbaut ist: https://www.geigerzaehlerforum.de/index.php?msg=22064 , wie das bei dem chinesischen Clone-Prozessor ist, weiß ich nicht.

Die Referenzzeit kommt von GeigerLog, welches die Zeit des Computers nimmt, auf dem es läuft. Die Zeit habe ich geprüft gegen die Atomzeit "Network time"(lässt sich innerhalb von GeigerLog machen) und sie stimmt innerhalb millisec überein. Damit ist für mich diese Referenzzeit "richtig".

Beim Loggen mit RadPro ruft GeigerLog das RadPro Kommando "GET deviceTime" auf, welches einen UNIX timestamp mit 1 sec Auflösung vom Device (bei mir GC-01) bekommt. Das Delta time-computer minus time-device ist dann recorded und geplottet als Clock Drift; im Beispiel auf Variable "Humid" .

Nach Datenblatt ist im ARM M3 eine RTC (Real Time Clock) integriert. Das ist attraktiv, da dann kein externer Chip benötigt wird und Kosten gespart werden. Natürlich benötigt diese eine Backup-Batterie. Und sie benötigt einen Zeitgeber. Der einzige Zeitgeber ist der "8.000 MHz" Quartz, aus dem durch Vervielfachung und Teilung die notwenigen Takte von 72MHz abwärts abgeleitet werden.

Damit hängt die Genauigkeit der Zeiten und somit auch der RTC von der Genauigkeit dieses Quartzes ab. Unter der Annahme, das alles billig sein muss, dürfte eher der schlechteste Quartz verwendet werden. Dieser hat nach Mouser 50ppm. Daraus rechne ich: 86400 sec/day * 50 ppm => 4.3 sec/day. Das ist ja ungefähr das, was ich gemessen habe!

Das kann man deutlich besser machen, aber auch deutlich schlechter. GQ's GMC counter sind bekannt für eine Drift von 20 sec/day! Das ist schon ziemlich ärgerlich schlecht. Und wie man sieht, geht es sogar bei halb so teuren Countern besser.

Stellt man zwischendurch die Uhr neu, kann es im Log zu einer Zeitumkehr kommen, was manche Auswertungen überhaupt nicht mögen. Deswegen kann man GeigerLog so konfigurieren, dass beim Loggen mit einem RadPro Device in einem Intervall <1h (Default 30min) die Device-Zeit gestellt wird, so dass eine Zeitumkehr stets zuverlässig vermieden wird.

Das Kommando zur Zeitstellung ist schnell. Es dauert nur ca. 3ms in der RadPro; bei GMC Countern ist es locker das 10fache!

Aber das geht nur, solange ich online bin, also per Kabel das Device mit GeigerLog verbunden habe. Ist das Device offline driftet die Clock! Dann besser erst wieder verstellen, wenn die Auswertung fertig ist :-).

 

Zitat von: ullix am 29. April 2024, 11:19Der einzige Zeitgeber ist der "8.000 MHz" Quartz

Und Du meinst, dass dieser 8-MHz-Oszillator auch im ausgeschaltenen Zustand läuft und die Zeitbasis für die Uhr aus der Knopfzelle bereitstellt?

wäre m.E. notwendig. Wenn nicht so, wie dann?

Auf den Platinen-Bildern des FNIRSI GC-01 ist ein zweiter, kleiner SMD-Quarz, nebst Beschaltung, zu erkennen. Vermutlich ist das ein Uhrenquarz. Der CH32F103C8 scheint *sehr* kompatibel zu sein, Low-Cost China-Module mit dem drauf haben regelmäßig einen Uhrenquarz (... dann auch im unverwechselbaren Uhrenquarz-Gehäuse).
Anders wäre auch die Speisung mit der Knopfzelle kaum machbar.
Insofern läuft die Uhr verdammt sicher mit einem 32,768kHz-Quarz. Die haben aber üblicherweise eher 20ppm als 50ppm.

Aber: (sehr wahrscheinlich) nur wenn das Gerät aus ist.
Also als Batterie-Backup-Uhr.
Läuft das Gerät, dann wird oft (=üblich) die Uhr von einem Timer bedient/hochgezählt, der aus dem Haupttakt kommt, hier also aus dem 8MHz-Quarz abgeleitet ist. Und der kann sehr gut 50ppm haben.

Anmerkung: 20 Sekunden/Tag sind 100ppm, das wird mit einem Quarz schwierig. Da kann man auch Software-Probleme vermuten. (Verbaselte Interrupts, falsch eingestellte Timer, Delay-Timer statt periodischer Timer: da summiert sich dann etwas variable Latenz über den Tag auf.)

Zitat von: Elektroniknerd am 29. April 2024, 12:32Auf den Platinen-Bildern des FNIRSI GC-01 ist ein zweiter, kleiner SMD-Quarz, nebst Beschaltung, zu erkennen. Vermutlich ist das ein Uhrenquarz.

Du meinst das mit "Y2" beschriftete Bauteil an der linken unteren Ecke des Prozessors?

https://raw.githubusercontent.com/Gissio/radpro/main/docs/devices/FNIRSI%20GC-01/img/gc-01-board-type.jpg

Ob aber wirklich im EINgeschaltenen Zustand die Taktquelle für die Echtzeituhr auf den 8MHz-Quarz umgeschwenkt wird? Das kann ich mir nicht vorstellen. Nur die Stromversorgung erfolgt nicht mehr aus der Knopfzelle, wenn der ganze Prozessor Strom hat.
Vielleicht kann man das mit einer kleinen Heizung in Form eines 1206-SMD-Widerstands herausfinden, mit der man die Quarze einzeln erwärmt und die Drift beobachtet.

Zitat von: DG0MG am 29. April 2024, 12:39Du meinst das mit "Y2" beschriftete Bauteil

Jepp, genau der ist es. Da sitzen ja auch gleich die üblichen "15pF" (C3 und C5) Kondensatoren neben, der andere Quarz heißt Y1 ... das sieht sehr eindeutig aus.

Zitat von: DG0MG am 29. April 2024, 12:39Das kann ich mir nicht vorstellen.

Ich habe es bisher immer so gemacht und es noch nirgends anders gesehen. Was nichts heißen muss - außer, das es nicht ungewöhnlich ist.

Man macht das schlichtweg, weil "Hardware-Uhr auslesen" lange, verdammt lange oder nervig elend lange dauert. Und man das bei Stoppuhrfunktion eigentlich gerne verdammt schnell wissen möchte. 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.

Zum Ausprobieren würde ich den Uhrenquarz einfach "anhalten", wenn man da auf der Eingangsseite mit einem 1:1 Tastkopf ran geht, reißt die Schwingung (typischerweise) ab. Und die zugehörige Uhr sollte stehenbleiben. (Auf der anderen Seite von Quarz misst man schlichtweg 32kHz, die ist niederohmig genug.)