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
 FFs in the data		  New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

Erwin55

Germany
41 Posts
Posted - 06/12/2023 :  09:48:09  Show Profile  Reply with Quote
Dear All, my new counter (GMC-320+V5 RRe) works well. Just a simple question, not a big issue, but an issue: In the downloaded data are FFs which are no valid data. Not at the end of a buffer, now buffer wrap arround, just in between (see the figure attached). Hence, what is the reason and how can I avoid this? Thanks for your advice in advance. Erwin
Edited by - Erwin55 on 06/12/2023 09:50:25
Reply #1

ullix

Germany
1171 Posts
Posted - 06/12/2023 :  22:43:13  Show Profile  Reply with Quote
This is probably due to the storage algorithm used. Read about it in the GeigerLog manual in chapter "Appendix E – GMC Device: Internal Memory, Storage Format and Parsing Strategy"

After downloading the counter memory into GeigerLog, you can call menu: History --> GMC Series --> Show History Binary Data as AA / FF Map. This will give an output like:


==== Show History Binary Data as Map of 0xAA and 0xFF ================================
from: geigerlog/data/test6.hisdb
One single printed character maps a chunk of 16 bytes of data
'A' marks occurence of value 0xAA in chunk (AA => DateTime String)
'F' marks occurence of value 0xFF in chunk (FF => empty value)
Byte No|    127|    255|    383|    511|    639|    767|    895|   1023|
      0|.........A...........A...........A...........A...........A......
   1024|.....A...........A...........A...........A...........A..........
   2048|.A...........A...........A...........A...........A...........A..
   3072|.........A...........A...........A...........A...........A......
   4096|.....A...........A...........A...........A...........A..........
   5120|.A...........A...........A...........A...........A...........A..
   6144|.........A...........A...........A...........A...........A......
   7168|.....A...........A...........A...........A...........A..........
lines removed
  48128|.A...........A...........A...........A...........A...........A..
  49152|.........A...........A...........A...........A...........A......
  50176|.....A...........A...........A...........A...........A..........
  51200|.A...........A...........A...........A...........A...........A..
  52224|.........A...........A...........A...........A...........A......
  53248|.....A...........A...........A...........A...........A..........
  54272|.A...........A...........A...........A...........A...........A..
  55296|.........A...........A...........A...........A...........A......
  56320|.....A...........A...........A...........A...........A..........
  57344|.A...........A...........A.....AA...........A.....AAA.FFFFFFFFFF
  58368|FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
  59392|FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
  60416|FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
  61440|.A...........A...........A...........A...........A...........A..
  62464|.........A...........A...........A...........A...........A......
  63488|.....A...........A...........A...........A...........A..........
  64512|.A...........A...........A...........A...........A...........A..
Byte No|    127|    255|    383|    511|    639|    767|    895|   1023|

Note the FF section in the middle separating the new data above (in the pic) from the old data below.
Go to Top of Page
Reply #2

Erwin55

Germany
41 Posts
Posted - 06/13/2023 :  00:34:03  Show Profile  Reply with Quote
Thank you for the advice. The FFs should occur at the end of a buffer. In your example above, the last FF is at the end of buffer 15 (61440/2^12), ok. But the ring buffer is not active in my data. The incriminated FFs range from 277434 to 277441 (8 total) and these are more or less in the middle of the 67th buffer. So definitely wrong. The end of data FFs are between 554245 and 557056 (136th buffer), ok also. The intent of my question is if anyone has also observed this behavior and if it is due to the counter's internal workload (sleep, download, key input, etc.) which I can avoid.
Go to Top of Page
Reply #3

Erwin55

Germany
41 Posts
Posted - 07/06/2023 :  06:28:54  Show Profile  Reply with Quote
Just to close this item: After several run-throughs of the whole memory it never happens again. Seems it was an accidental error. The counter works fine and I'm happy.
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.06 sec. Snitz's Forums 2000