| Author |
 Topic  |
|
|
ullix
Germany
974 Posts |
 Posted - 03/11/2023 : 01:56:06
|
I notice a problem with a new GMC-300SRe 1.03 counter which severely impacts reliable data recording.
This is a problem which I am seeing for the first time in any GMC counter; never happened before neither in my data nor in data which I have seen from users of GeigerLog.
This is the problem: next pic shows a recording with approx. CPS=50 average. But every now and then there are spikes up to almost CPS=3000, and all spikes are nearly the same. This is utterly impossible. One wonders: CPS=50 results in CPM=3000. Hmm.
Zooming-in into one of those spikes, and also overlapping with CPM, gives this result:
One can now see that the call to CPM had failed - i.e. delivered no value, here shown as "-100" - and the following call to CPS then delivered the missed CPM value, and NOT the CPS value!
Since I do clear the serial port pipeline before each call from GeigerLog, this is not due to values "stuck in the pipeline now being dug out", this is a bug coming from within the counter!
Almost needless to show, but overlapping with Audio CPM/CPS recorded simultaneously from the same counter shows no such mess-up:
And there is more. Next pic shows how the CPS calls failed. Such failures are almost all due to a timeout within 500ms. This period is about 100times longer than the typical response of the counter from 3...5ms.
In the recording period shown some 250 of those timeouts happened. I have seen timeouts before with other counters, but not in that high frequency!
My suspicion: this new counter uses a weaker CPU than the older counters, which can't keep up with the demand. If not the case, then some bug was introduced into this firmware!
|
|
| Reply #1
Damien68
France
760 Posts |
Posted - 03/11/2023 : 03:06:03
|
it looks like transmission bugs in both directions.
another possible cause can be if the counter UART is not exactly at 115200 baud. it can be checked with an oscilloscope (in the Tx and Rx direction). |
Mastery is acquired by studying, with it everything becomes simple |
 |
|
| Reply #2
ullix
Germany
974 Posts |
Posted - 03/11/2023 : 04:05:02
|
The default baudrate of the 300S counter is 57600, and this is the setting used.
Like the old 300E+, which also has 57600 as default. With that one I noticed occasional communication problems when set to 115200, so GeigerLog sets the default to the official default of 57600.
You can change it in the GeigerLog configuration, but I recommend against it.
Though even this old counter didn't have the problems observed now.
|
|
|
| Reply #3
EmfDev
1925 Posts |
Posted - 03/13/2023 : 12:06:31
|
| Is this by using GETCPM or GETCPS? |
|
|
| Reply #4
ullix
Germany
974 Posts |
Posted - 03/14/2023 : 00:27:14
|
Both. Otherwise I could not have shown how values were swapped between CPM and CPS.
Actually, I also used commands for CPM1st, CPS1st, CPM2nd, CPS2nd, i.e. 6 commands in total.
Of course, there is only a single tube in the 300S, but I am sure you are aware that the firmware ignores all extra letters, so even "<GETCPMXYZabc>>" and "<GETCPSXYZabc>>" will deliver exact same as CPM, and CPS, resp.
|
|
|
| Reply #5
ullix
Germany
974 Posts |
Posted - 03/15/2023 : 02:56:09
|
The next problem with this 300S counter is that its clock looks like being the worst a GMC counter has ever had, with respect to time keeping.
I have adapted GeigerLog to measure the time difference between the ComputerTime and the CounterTime. I verified that my computer ran with millisecond accuracy (no surprise, because it it synchronized with WEB-Time Servers' atomic clocks). Here is a run over nearly a full day:
There are two things to be concerned about:
First, there is a drift of 20.7 seconds per day. It runs faster than it should be. This is a lot!
I have another project with a microchip and a real-time clock, and there I have to measure time variance in milliseconds per year in order to see variation! The GMC counter drift is well over a million times worse! There is a lot room for improvements.
Second, there are these spikes, marked with a "?". There are 7 of them over a 24h period.
Each one represents a jump of 1 full minute in the clock time. This can really be a problem for any program reading the data.
GeigerLog is ignoring the counter's clock when logging, but obviously must rely on it when downloading the history from the counter, as this clock time is part of the history.
|
|
|
| Reply #6
EmfDev
1925 Posts |
Posted - 03/15/2023 : 09:38:51
|
| Will let our team know and see if they can produce the same results. |
|
|
| Reply #7
ullix
Germany
974 Posts |
Posted - 03/15/2023 : 23:52:07
|
I didn't expect a difference, but did run with different baudrate anyway, this time 115200 versus before 57600.
Indeed, no difference, the clock is really bad irrespective of baudrate.
 |
|
|
| Reply #8
Damien68
France
760 Posts |
Posted - 03/17/2023 : 01:16:54
|
to be sure that it is not simply a synchronization problem between the RTC and the CPU, if you switch off and on again the counter, is the lag persistent?
if it persistent, +20s/day is roughly the error it would have if it mount a quartz trimmed to a load of 12pF or 18pF instead a quartz trimmed to a load of 6pF like required in the RTC DS1302Z datasheet.
if you want to slow down the clock, you can try to add two 12pF capacitors, one between each of the 2 wires of the quartz and the PCB ground, this will increase the load on the quartz by 12pF/2 = 6 pF and slow down the clock.
https://electronics.stackexchange.com/questions/566036/load-frequency-calculation-of-quartz-with-its-load-capacitance |
Mastery is acquired by studying, with it everything becomes simple |
Edited by - Damien68 on 03/17/2023 02:04:59 |
|
|
| Reply #9
ullix
Germany
974 Posts |
Posted - 03/18/2023 : 01:55:30
|
@Damien: not sure what you really wanted, but here is what I thought you meant.
Again, running the GMC-300S and measuring the difference between Computer Time (= True time) and what the counter's clock showed.
At the indicated time points I "power-cycled", which is:
- stop logging
- switch counter power off (from within GeigerLog)
- restart GeigerLog
- switch counter power on (from within GeigerLog)
- start logging
I think it can't get much weirder than that. And all this WITH a real-time-clock? I don't think so.
The GMC-300S really has a clock problem. |
|
|
| Reply #10
Damien68
France
760 Posts |
Posted - 03/18/2023 : 09:28:00
|
@ullix: the most common use with an RTC, is to read it once at boot time and it is saved in registers in the CPU RAM, then every second these registers are incremented,
this can be seen as an internal CPU clock. then, for example, every hour we will refresh the time by re-reading the RTC. and in any case we refresh it at midnight to get the new date.
but this is not necessarily what is done.
also the time lag can have several origins.
indeed the behavior during reboot is difficult to understand. |
Mastery is acquired by studying, with it everything becomes simple |
Edited by - Damien68 on 03/18/2023 09:34:53 |
|
|
| Reply #11
ullix
Germany
974 Posts |
Posted - 03/22/2023 : 23:41:47
|
More problems with the new GMC-300S. It can't properly handle even minor count rates.
The normal duration for a call for CPM or CPS is about 5 millisecond. The timeout is set for 500 millisecond, so 100 times as long. Yet, the CPS call can't handle this and it is raining timeouts - but only when the CPS is moderately high at CPS=75.
When we have only CPS=4.3, then the counter is able to cope with it!
This is only a fraction of what is claimed the counter can handle.
It looks again like the new GMC-300S is SIGNIFICANTLY under-powered! |
|
|
| Reply #12
traveler
Netherlands
11 Posts |
Posted - 03/23/2023 : 22:49:36
|
Does the (new) 320S has these issues as well?
|
|
|
| Reply #13
ullix
Germany
974 Posts |
Posted - 03/23/2023 : 23:03:16
|
| Very likely. Basically same board, same firmware. |
|
|
| Reply #14
traveler
Netherlands
11 Posts |
Posted - 03/23/2023 : 23:35:40
|
| Thanks thats what i also thought. |
|
|
| Reply #15
ullix
Germany
974 Posts |
Posted - 03/26/2023 : 23:06:19
|
To give a positive counter-example to the buggy GMC-300S: here is an overnight recording from a GMC-500+:
Compare this with the GMC-300S pics in the starting post and in Reply#11.The 300S saw CPS=50 and CPS=75, resp., and it was raining timeouts. No timeouts were found with low count rates, CPS=4.3 (Reply#11).
This current 500+ run had even CPS=110 and not a single timeout. And it passed the Poisson check with flying colors!
The timeout is set to 500millisecond. The normal operation takes under 5ms.
It is not believable that even a slower hardware, as the 300S might have, cannot cope with something which takes 5 ms when given 100 times the time.
Instead, all points to major flaws in firmware programming. Are these still the same people who put NULLs into the midst of C-strings?
|
|
|
| Reply #16
EmfDev
1925 Posts |
Posted - 03/27/2023 : 11:48:45
|
| It seems the communication between the software and device is not synced well and sometimes stuck. The device should not be affected by high CPM since it is using a hardware counter dedicated to counts. |
|
|
| Reply #17
traveler
Netherlands
11 Posts |
Posted - 03/27/2023 : 20:04:14
|
| Yesterday i bought the 300s... |
|
|
| Reply #18
ullix
Germany
974 Posts |
Posted - 03/27/2023 : 23:51:45
|
quote:
Originally posted by EmfDev
... The device should not be affected by high CPM since it is using a hardware counter dedicated to counts.
No disagreement here, it should not. But it is! What are you doing about it?
|
|
|
| Reply #19
ullix
Germany
974 Posts |
Posted - 03/30/2023 : 03:28:26
|
As the GMC-300E+ is so close to the new 300S, I wondered how it would perform in the same scenario as the 300S. And, as expected, it showed the same bugs.
At CPS=87 it rained timeouts. Surprisingly even more at the lower CPS=50. But, miraculously, no timeouts with only marginally lower CPS=29.
I conclude that the counter is useful only at low count rates, limited between CPS=29 and CPS=50.
Given that your manuals state for these counters:
quote:
Range of dose rate indications, #956;Sv/h 0.00 to 327.99
At your own specification of a counter sensitivity of 154 CPM /(uSv/h) you are claiming that the counters can record up to
327.99 * 154 => CPM=50510 and CPS=842
I'd say you are not even remotely there, but more than 10fold, perhaps even 30fold, lower! This amounts to false advertising. Do you agree?
I looked up the microprocessors used in these counters, and found:
GMC-300E+: STC 15L260S2
GMC-300S : STC 8A8K64D4
GMC-500+ : ARM STM32F103
The first two seem to be modern versions of the outdate model IBM8051. I can't tell if either one is faster than the other. Does anybody know?
The ARM chip is a more modern chip, and the only one which managed moderate count rates of CPS=100.
|
|
|
| Reply #20
Damien68
France
760 Posts |
Posted - 03/31/2023 : 00:40:13
|
I found the datasheet of the beast:
https://datasheetspdf.com/pdf-file/1305880/STCMCU/STC8A8K64S4A12/1
the 8051 architecture is a very great classic always used in microelectronics as a copy paste when looking for a small basic microcontroller.
concerning this issue, one of the main differences with ARM architectures is that on 8051 the UART have a hardware buffer of only 1 byte in reading and another one of 1 byte in writing (at the same address but different), whereas in the ARM architectures we have rather hardware buffers of 4 or 7 bytes or more with in addition pipe and DMA access to empty it.
concretely in the case of the 8051, it is necessary to fetch at each interuption triggered by each bytes received each bytes one by one and before it is overwritten by the next one. whereas with an ARM architecture , the emptying is done more or less automatically and is necessarily less critical.
but if you manage your interruptions and your priorities well, it should be able to work without worries with an 8051.
at 57600 bauds this leaves a deadline of (8+2)/57600= 173uS for each byte to fetch it from its hardware buffer
The bug could come from something else but normally it should be able to work. especially since apparently it is the last byte that does not pass (not sure).
it looks more like a beug in the management of interrupts or their acknowledgment/clearance. |
Mastery is acquired by studying, with it everything becomes simple |
Edited by - Damien68 on 03/31/2023 01:02:23 |
|
|
| |
Topic |
|
Bug in new GMC-300S counter
