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

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
Erwin55 Posted - 06/12/2023 : 09:48:09
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
3   L A T E S T    R E P L I E S    (Newest First)
Erwin55 Posted - 07/06/2023 : 06:28:54
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.
Erwin55 Posted - 06/13/2023 : 00:34:03
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.
ullix Posted - 06/12/2023 : 22:43:13
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.


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