| T O P I C R E V I E W |
| ikerrg |
Posted - 09/11/2018 : 03:36:51
@EmfDev: Could you try loading and exporting to .csv the following memory download (https://www.dropbox.com/s/l7x5pevt9lw1l4k/20180911_09_42_58.rar?dl=0) in DataViewer 2.53?
There are plenty of minutes when there are only 59 seconds measured. There are also gaps in the data, with no measurement during several seconds. Could you explain that? |
| 15 L A T E S T R E P L I E S (Newest First) |
| EmfDev |
Posted - 09/13/2018 : 13:56:09
It's updated again. But we will update the changes in the future.
I answered it in reply#11. Reading SPI is a loop so it will need to finish this read then will save the data after
when the cpu is not busy. Also, it is using the same resource as saving the data. |
| ikerrg |
Posted - 09/13/2018 : 13:31:05
I had checked that document, but it is still in revision 1.2 from sept-2017. You should update the revision and date, it is not a good practice not to record the changes in documents.
On the other hand, could you answer the other question I asked in reply #10: Can the memory be read through the USB connection (serial port) while the device is saving to it? Would it have the same effect of stopping the logging to memory? |
| EmfDev |
Posted - 09/13/2018 : 11:32:46
http://www.gqelectronicsllc.com/GMC-500UserGuide.pdf page17 |
| ikerrg |
Posted - 09/13/2018 : 11:21:49
Could you show the link to the updated documentation? |
| EmfDev |
Posted - 09/13/2018 : 08:40:50
Yes, that makes sense. It was already there since the 300 and 320 series. There could have been problem
with them having low on memory (sharing resources) or something else. So we'll just keep it there
so it doesn't produce some bugs. As for the documentation, I'll have to check.
Yes, reading the memory will use the same resource as writing through it. So after reading, it should queue the next save(or vice versa), so it will only miss few millisec or at max few seconds if reading too many.
Edit. It's not on the documentation.
Edit. It's now on the documentation. |
| ikerrg |
Posted - 09/13/2018 : 00:02:06
Wow! I didn't know that! So you cannot read the memory to display on the screen and continue saving to it at the same time? You should have a buffer where you store the readings until you can write them to memory when it is free to access. Is that limitation indicated anywhere in the documentation?
Another question: Can the memory be read through the USB connection (serial port) while the device is saving to it? Would it have the same effect of stopping the logging to memory?
|
| EmfDev |
Posted - 09/12/2018 : 15:46:03
Yes it's in the code that if you're in the history scree, it won't save data. Maybe that's the reason for the missing data. |
| ikerrg |
Posted - 09/12/2018 : 14:51:32
This is just to add some info to how I recorded the data. After removing the M4011 tube (the device was off) I closed the device and turned it on. I then deleted the history file (to start from scratch) and I went to the airport. I never turned off the device again until the plane landed, but I was playing with it many times, touching buttons and viewing the history on screen (to see the xray readings). Could that watching of the recorded history on the device's screen intefere with the write to the internal memory? Something related to priorities? |
| EmfDev |
Posted - 09/12/2018 : 10:27:12
I checked the bin file and looks like the raw data is wrong. Missing 1 data is ok(the cpu clock is longer by a little bit) but the skipped timestamp 2x
17:26:08 and 17:35:12 looks like a bug. The first 2 lines might be due to turning on/off when changing the tube and
when changing the save data as setting(minutely, secondly, etc), but the one in the middle doesn't look good.
I've attached a bin file for 500+ that's recorded since the 10th.
This one suppose to have 1440 lines in csv for the whole day of 11th.
But only 1437(maybe difference in clock). It looks like it didn't really miss a lot of minutes for the entire day. Only missed the
minutes not the counts.
Download Attachment: 
1048832 |
| ikerrg |
Posted - 09/12/2018 : 02:45:07
Thanks ullix for confirming. Therefore, the problem is in the raw data, not in the .csv parsing of Data Viewer 2.53. Another firmware bug?
|
| ullix |
Posted - 09/11/2018 : 23:40:23
I find nothing wrong with the data when analyzed in GeigerLog. Manually looking at a bunch of the DateTime tags they were all 180 samples apart. No gaps found.
Though for the reasons given by EmfDev (synchrony of two clocks) I would not be surprised if there were a jitter of at least 1 second.
Can you specify time points where you saw gaps?
Update: I stand corrected; there are indeed a significant number of count-records missing:
2018-09-10 16:09:16 DeltaT[sec]: 267 count-recs: 200 missing count-recs: 67
2018-09-10 16:10:42 DeltaT[sec]: 86 count-recs: 44 missing count-recs: 42
2018-09-10 16:13:46 DeltaT[sec]: 184 count-recs: 175 missing count-recs: 9
2018-09-10 16:16:46 DeltaT[sec]: 180 count-recs: 180 missing count-recs: 0
2018-09-10 16:19:47 DeltaT[sec]: 181 count-recs: 180 missing count-recs: 1
2018-09-10 16:22:48 DeltaT[sec]: 181 count-recs: 180 missing count-recs: 1
2018-09-10 16:25:49 DeltaT[sec]: 181 count-recs: 180 missing count-recs: 1
2018-09-10 16:28:49 DeltaT[sec]: 180 count-recs: 180 missing count-recs: 0
2018-09-10 16:31:50 DeltaT[sec]: 181 count-recs: 180 missing count-recs: 1
2018-09-10 16:34:51 DeltaT[sec]: 181 count-recs: 180 missing count-recs: 1
2018-09-10 16:37:52 DeltaT[sec]: 181 count-recs: 180 missing count-recs: 1
2018-09-10 16:40:53 DeltaT[sec]: 181 count-recs: 180 missing count-recs: 1
2018-09-10 16:43:53 DeltaT[sec]: 180 count-recs: 180 missing count-recs: 0
2018-09-10 16:46:54 DeltaT[sec]: 181 count-recs: 180 missing count-recs: 1
2018-09-10 16:49:55 DeltaT[sec]: 181 count-recs: 180 missing count-recs: 1
2018-09-10 16:52:56 DeltaT[sec]: 181 count-recs: 180 missing count-recs: 1
2018-09-10 16:55:56 DeltaT[sec]: 180 count-recs: 180 missing count-recs: 0
2018-09-10 16:58:57 DeltaT[sec]: 181 count-recs: 180 missing count-recs: 1
2018-09-10 17:01:58 DeltaT[sec]: 181 count-recs: 180 missing count-recs: 1
2018-09-10 17:04:59 DeltaT[sec]: 181 count-recs: 180 missing count-recs: 1
2018-09-10 17:07:59 DeltaT[sec]: 180 count-recs: 180 missing count-recs: 0
2018-09-10 17:11:05 DeltaT[sec]: 186 count-recs: 132 missing count-recs: 54
2018-09-10 17:14:05 DeltaT[sec]: 180 count-recs: 163 missing count-recs: 17
2018-09-10 17:17:06 DeltaT[sec]: 181 count-recs: 180 missing count-recs: 1
2018-09-10 17:20:06 DeltaT[sec]: 180 count-recs: 180 missing count-recs: 0
2018-09-10 17:23:07 DeltaT[sec]: 181 count-recs: 180 missing count-recs: 1
2018-09-10 17:26:08 DeltaT[sec]: 181 count-recs: 180 missing count-recs: 1
2018-09-10 17:35:12 DeltaT[sec]: 544 count-recs: 292 missing count-recs: 252
2018-09-10 17:38:13 DeltaT[sec]: 181 count-recs: 180 missing count-recs: 1
2018-09-10 17:41:15 DeltaT[sec]: 182 count-recs: 180 missing count-recs: 2
2018-09-10 17:44:16 DeltaT[sec]: 181 count-recs: 175 missing count-recs: 6
2018-09-10 17:47:16 DeltaT[sec]: 180 count-recs: 180 missing count-recs: 0
In the most extreme case there is no DateTime tag for 9 min, and 252 out of the expected 544 recs are missing. The bordering time tags are ok:
# 5095, 2018-09-10 17:26:08, Date&Time Stamp; Type:'CPS, save every second', Interval:1 sec
# 5399, 2018-09-10 17:35:12, Date&Time Stamp; Type:'CPS, save every second', Interval:1 sec
|
| ikerrg |
Posted - 09/11/2018 : 12:58:31
No, the device was on during the whole recording time, from when I reached the airport to a bit after I landed. |
| EmfDev |
Posted - 09/11/2018 : 12:25:32
Did you maybe turn off the device during those times?
I think the memory/bin file is correct. But the parsing is wrong. |
| ikerrg |
Posted - 09/11/2018 : 12:21:59
So the binary file is also wrong? I thought it could be a parsing problem when converting to .csv. The last time I recorded data ( https://www.dropbox.com/s/vlq4zkk8ee2rnhf/20180817_21_36_37.rar?dl=0 ) some gaps appeared in the .csv file, but they were not so many as in the new recording. Both measurements have been done with the firmware version 1.21.
I trust you guys to find the origin of the problem.
|
| EmfDev |
Posted - 09/11/2018 : 10:43:34
Looks like we need to check to see where it went wrong. But what I can say is that there might not be exactly 180 second data in 3 minutes because of the difference in the software timer and the real time clock. |
