GQ Electronics Technical Support Forum


GQ Electronics Technical Support Forum
Home | Profile | Register | Active Topics | Members | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 GQ Electronics Forums
 2.GQ Geiger Muller Counter
 Exporting to csv in Data Viewer 2.53
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

ikerrg

United Kingdom
293 Posts

Posted - 09/11/2018 :  03:36:51  Show Profile  Reply with Quote
@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?
Reply #1

EmfDev

311 Posts

Posted - 09/11/2018 :  10:43:34  Show Profile  Reply with Quote
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.
Go to Top of Page
Reply #2

ikerrg

United Kingdom
293 Posts

Posted - 09/11/2018 :  12:21:59  Show Profile  Reply with Quote
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.

Go to Top of Page
Reply #3

EmfDev

311 Posts

Posted - 09/11/2018 :  12:25:32  Show Profile  Reply with Quote
Did you maybe turn off the device during those times?

I think the memory/bin file is correct. But the parsing is wrong.

Edited by - EmfDev on 09/11/2018 12:26:35
Go to Top of Page
Reply #4

ikerrg

United Kingdom
293 Posts

Posted - 09/11/2018 :  12:58:31  Show Profile  Reply with Quote
No, the device was on during the whole recording time, from when I reached the airport to a bit after I landed.
Go to Top of Page
Reply #5

ullix

Germany
346 Posts

Posted - 09/11/2018 :  23:40:23  Show Profile  Reply with Quote
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



Edited by - ullix on 09/12/2018 02:39:15
Go to Top of Page
Reply #6

ikerrg

United Kingdom
293 Posts

Posted - 09/12/2018 :  02:45:07  Show Profile  Reply with Quote
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?

Go to Top of Page
Reply #7

EmfDev

311 Posts

Posted - 09/12/2018 :  10:27:12  Show Profile  Reply with Quote
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

Edited by - EmfDev on 09/12/2018 13:55:33
Go to Top of Page
Reply #8

ikerrg

United Kingdom
293 Posts

Posted - 09/12/2018 :  14:51:32  Show Profile  Reply with Quote
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?
Go to Top of Page
Reply #9

EmfDev

311 Posts

Posted - 09/12/2018 :  15:46:03  Show Profile  Reply with Quote
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.
Go to Top of Page
Reply #10

ikerrg

United Kingdom
293 Posts

Posted - 09/13/2018 :  00:02:06  Show Profile  Reply with Quote
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?
Go to Top of Page
Reply #11

EmfDev

311 Posts

Posted - 09/13/2018 :  08:40:50  Show Profile  Reply with Quote
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.

Edited by - EmfDev on 09/13/2018 10:48:24
Go to Top of Page
Reply #12

ikerrg

United Kingdom
293 Posts

Posted - 09/13/2018 :  11:21:49  Show Profile  Reply with Quote
Could you show the link to the updated documentation?
Go to Top of Page
Reply #13

EmfDev

311 Posts

Posted - 09/13/2018 :  11:32:46  Show Profile  Reply with Quote
http://www.gqelectronicsllc.com/GMC-500UserGuide.pdf page17
Go to Top of Page
Reply #14

ikerrg

United Kingdom
293 Posts

Posted - 09/13/2018 :  13:31:05  Show Profile  Reply with Quote
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?
Go to Top of Page
Reply #15

EmfDev

311 Posts

Posted - 09/13/2018 :  13:56:09  Show Profile  Reply with Quote
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.
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
GQ Electronics Technical Support Forum © Copyright since 2011 Go To Top Of Page
Generated in 0.19 sec. Snitz Forums 2000