| T O P I C R E V I E W |
| ullix |
Posted - 11/28/2021 : 06:37:58
I am doing some in-depth tests on my next GeigerLog release, and found something strange:
I ran a GMC500+ in GeigerLog at only background radiation, requesting only CPM1st, the CPM for the 1st tube, at a 1 sec cycle via a USB-to-Serial connection at 115200 baud. Shown as light blue in the picture. The sparsely dotted brown curve is the WiFi transmitted CPM (which inappropriately sends the sum of both CPM1st and CPM2nd, but at background CPM2nd is very low, and barely noticeable.). This goes at 1 min cycle time, the fastest possible.
The green garden-fence is the duration in milliseconds (right Y-axis) of one of the light-blue calls, measured and recorded by GeigerLog.
The fence-planks repeat at a highly consistent interval of 5.6 min. It stays this way forever (at least overnight).
A detail of one plank is in the next pic. It always has a width of 26 sec, so exactly 26 samples 1 sec apart, and a shape of a house with a single-pitched roof. Every now and then a much higher single-sec spike comes on top of it. The "normal" duration is at 3.5 millisec with very little spread.
So at some point the cpu has a lot of work to do, and increasingly more up to the end of 26 sec, and then goes back to idle?
I wonder where this comes from. Even for a low-powered cpu as in this counter, 26 sec are long, near an eternity! It also does not have anything to do with WiFi activity, see the position of the two brown dots well outside this pitch-roof building.
|
| 2 L A T E S T R E P L I E S (Newest First) |
| Damien68 |
Posted - 11/30/2021 : 08:44:52
the curve for the 500 clearly shows an aliasing effect (to be taken in the broad sense, it is not a term reserved for video):
this is just a possible scenario:
1. every second the GMC must perform a task to refresh its screen and perform various things which must take approximately 100mS.
2. Every second GeigerLog interrogates the GMC to obtain the current CPM.
the problem is that this two actions are not directly synchronized, but synchronized with two different clocks. as the two frequencies are almost the same but slightly different, we observe a slippage ie at times the USB request will arrive during the period when the GMC-500 is occupied.
we can notice that the cycle takes 5.6 minutes that will mean that we have a shift between the 2 clocks (PC / GMC) of 1 second every 5.6min
the difference of the 2 clocks is therefore 1/(5.6*60) = 0.3% certainly either the PC or the GMC does not use an independent event generator but must use a timer to clock its business. but it doesn't change much
for the 300E, it is actually less clear what is going on.
in any case it's just a possibility which is consistent, but there is also the CH340 chip, its driver, and also Linux which can interfere and add latencies.
EDIT: if my theory is true, as the roof of the house is tilting to the left, it will mean that the PC 1 second timebase is shorter than the GMC 1 second timebase by 0.3% |
| ullix |
Posted - 11/30/2021 : 05:51:49
I repeated the experiment, but now with a GMC300E+ counter, showing only the duration it takes to make a single CPM reading.
Such reading takes from 4.5 ms up to 350 ms! There is no regularity that I can make out. About twice per hour, and lasting 10 to 20 min the counter gets really lazy.
Since I called the GMC500 results "strange", I am not sure what to call these ones?
|
|
|
