GeigerLog & RadPro an FNIRSI GC-01

[ullix]

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 :-/

[Dsl71]

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!

[ullix]

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.

[ullix]

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.

[Dsl71]

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

[Gissio]

* 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?

[ullix]

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/