GQ Electronics Technical Support Forum Active Users: / Visits Today:
Highest Active Users:
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

Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!

Screensize:
UserName:
Password:
Format Mode:
Format: BoldItalicizedUnderlineStrikethrough Align LeftCenteredAlign Right Horizontal Rule Insert HyperlinkInsert EmailInsert Image Insert CodeInsert QuoteInsert List Spell Checker
   
Message:

* HTML is OFF
* Forum Code is ON
Smilies
Smile [:)] Big Smile [:D] Cool [8D] Blush [:I]
Tongue [:P] Evil [):] Wink [;)] Clown [:o)]
Black Eye [B)] Eight Ball [8] Frown [:(] Shy [8)]
Shocked [:0] Angry [:(!] Dead [xx(] Sleepy [|)]
Kisses [:X] Approve [^] Disapprove [V] Question [?]

   Insert an Image File
Check here to include your profile signature.
    

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.

GQ Electronics Technical Support Forum © Copyright since 2011 Go To Top Of Page
Generated in 0.06 sec. Snitz's Forums 2000