| Author |
 Topic  |
|
|
ikerrg
United Kingdom
334 Posts |
 Posted - 12/01/2018 : 01:24:41
|
Hi,
Yesterday I recorded during some time with my GMC-500+V2. When trying to download the data using DataViewer, it just freezes after successfully downloading. The binary file is stored, but not correctly processed by DataViewer. Trying to find the reason of the problem, I opened the binary file with GeigerLog, and here is the graph!
Image Insert:
81609 bytes
The graph is identical if I download the GMC memory using GeigerLog instead of DataViewer (both files are identical indeed, apart from a small header added by GeigerLog).
You can download the file here: https://www.dropbox.com/s/rxyzgjt8znyyuj4/20181201_09_11_42.zip?dl=0
I wonder is all these problems are related to the new codes (55 AA 05 and so) introduced in the newest firmwares, which cannot be parsed by any of the software.
I cannot understand how long it is taking to fix DataViewer to be compatible with the new firmwares. It is not only this problem, it is also the problem with the parsing to .csv (not all the counts are shown in every minute, etc.)
|
Edited by - ikerrg on 12/01/2018 01:27:55
|
|
| Reply #1
ullix
Germany
1171 Posts |
Posted - 12/01/2018 : 03:03:19
|
Negative values always result when GeigerLog cannot interpret the data due to a non defined code (see manual).
In this case I confirm that it is indeed due to the new 55 AA 05 code.
GeigerLog catches up to the correct interpretation when another and correct DateTime tag comes along. So a work around is to just ignore/eliminate all negative values, the rest is ok.
But I noticed additional inconsistencies, for which I need help.
Your bin file is not just 1MB, it is 1MB+256Bytes. In your case those 256 extra bytes are just 0xFF, and GeigerLog ignores them. (Don't know what the Dataviewers do?) But I have seen other bin files, where those extra bytes contained a sequence like "www.gmcmap.com". Those bytes result in wrong information!
My interpretation is that all or part of the configuration memory, which is separate from the data memory, is attached.
For what purpose, I am wondering, because there is no information relevant to the interpretation of the data in it?
And if the config memory is attached, does it mean that in the 500/600 series there are 512 bytes attached instead of 256? And if not, it makes even less sense.
Are the bin files identical when downloaded with the Dataviewer or its "pro" version?
I'd like to see bin files downloaded with DV, DV Pro, GeigerLog, and from the 300, 500, and 600 series counters.
GeigerLog only downloads the data memory, and attaches a header identifying the counter type and date of download. At least this helps with the interprtation of the data.
Yet more undefined stuff in the firmware...
|
 |
|
| Reply #2
ikerrg
United Kingdom
334 Posts |
Posted - 12/01/2018 : 11:39:50
|
| I suppose EmfDev will answer us next Monday. It seems odd that they included features in the newest 500/600 firmwares that make the DataViewer software totally useless to view the data (at least it downloads the memory but then freezes). DataViewer requires a complete review in order to make it usable. Thanks that you wrote GeigerLog, ullix! |
|
|
| Reply #3
EmfDev
2250 Posts |
Posted - 12/03/2018 : 14:16:23
|
@ullix,
The 256 bytes are configuration data. And its purpose is for the calibration data for this device so it didn't matter for 500/600. |
|
|
| Reply #4
ullix
Germany
1171 Posts |
Posted - 12/04/2018 : 03:00:57
|
@EmfDev: again, please be a bit more specific. So far, my understanding is:
- The history downloads from the 500, 600 and later series devices do NOT have this 256 bytes configuration memory content attached
- The 300 counters have 256 bytes attached to the 64k downlaod
- The 320 counters have 256 bytes attached to the 1M download
Is that correct?
|
|
|
| Reply #5
EmfDev
2250 Posts |
Posted - 12/04/2018 : 13:45:31
|
Edit. The data viewer has been updated.
You are correct for the 300 and 320.
300 -> 64kB + 256bytes
320 -> 1M + 256bytes
Now for the 500/600 series -> 1M+512Bytes
Previously, the 500/600' 256bytes are all FF's but now it should be 512Bytes of configuration. This configuration data is for future reference.
|
Edited by - EmfDev on 12/04/2018 16:22:09 |
|
|
| Reply #6
ikerrg
United Kingdom
334 Posts |
Posted - 12/05/2018 : 02:21:05
|
| @EmfDev: Have you tried opening the file in my first post of this thread with the new DataViewer 2.55 and saving it to .csv? It opens the file correctly, but it freezes in the same way as before when converting the data to .csv. |
|
|
| Reply #7
EmfDev
2250 Posts |
Posted - 12/05/2018 : 16:39:49
|
@ikerrg
Oh, yeap it seems like there's another bug, we will fix it and update the firmware when finished.
Thanks for letting us know. |
|
|
| Reply #8
ikerrg
United Kingdom
334 Posts |
Posted - 12/10/2018 : 02:15:52
|
So this problem about the tube identification (55 AA 05) is getting weirder! Yesterday I tried testing the new GeigerLog version by first recording during some time with the GMC-500+ while I changed the tube selection several times. The files in here https://www.dropbox.com/s/af4efoaz6or4do4/testmultitube.zip?dl=0 are the memory downloads using DataViewer 2.55 (which still freezes after downloading, by the way). When I opened the files with GeigerLog, I found that the tube identification had not been changed while I did the recording. I tried downloading the memory using GeigerLog but the result was the same, no tube identification during the multiple times I changed the tube selection (you can indirectly see the tube being used in the CPM).
So it is the firmware of the GMC-500+ who is not saving the tube identification when the tube selection is changed during a recording. Please @EmfDev, could you confirm how the firmware works in that sense? If the tube selection code 55AA05XX is not recorded to the memory when the tube selection is changed, then there is no point in having it.
|
|
|
| Reply #9
ullix
Germany
1171 Posts |
Posted - 12/10/2018 : 09:17:13
|
Weird indeed. In your file from Dec9 there is not a single "Tube Selected" tag. In that from Dec10 I see three, all of the type 0 (i.e. both tubes), yet the graphic Time Course suggests there should be at least 6, and they should be of different type.
Your file from Dec1 had two such tags, and both of type 1 (i.e. first tube only); at least that did seem to make sense. So it can save a tag of type 1 in principle.
Slightly weird: I see at the end of every file an odd succession of Date&Time stamps going through various savings options. Is that something you do manually or some kind created by the counter itself in the shut down process?
But more on true weirdness: if you want to know your password from your private, secret WiFi installation, just ask me. Or take a Hex viewer and look at the last 512 bytes of the bin file downloaded by DataViewer.
In addition to WiFi SSID and Password, there are also the gmcmap user and device details included, so anyone could post to the GMCMAP real or wrong data in somebody else's name. And could visit you at home, if you did honestly give your locations lat/lon coordinates!
Is there perhaps a slight security issue by including the full configuration memory to the data memory download, exaggerated by not telling about its inclusion?
What is gained by this inclusion; it does not even tell you what device the history is downloaded from?
|
|
|
| Reply #10
ikerrg
United Kingdom
334 Posts |
Posted - 12/10/2018 : 09:32:01
|
quote:
Slightly weird: I see at the end of every file an odd succession of Date&Time stamps going through various savings options. Is that something you do manually or some kind created by the counter itself in the shut down process?
That is right. I always stop the data saving before turning off the counter (so it does not start saving after turn on next time). In order to do that, I have to go through all the options in the list, and no matter how quick I go through them, they are recorded to the internal memory.
I already noticed that the configuration data is not very private in these counters. The wifi password could only be interesting if I have a neighbour reading this forum (quite unlikely). I do not mind if somebody starts adding data to the World Map using my device's ID, it is annoying, but not dangerous. The thing about the GPS coordinates is a bit more concerning, but I have not defined the exact position anyway. In any case, GQ should warn about disclosing private data if memory files are shared! Imagine if I worked in Area 51 measuring alien radiation and I inadvertently disclose the location of the facility!
|
|
|
| Reply #11
Sonicmixmaster
USA
75 Posts |
Posted - 12/13/2018 : 23:48:30
|
| I don’t know if this is related but I have been running my counter on my window for over a month and I wanted to see if it’s working correctly so I’ve plugged it in today and downloading data is stuck at zero and goes nowhere. Why are there still problems with this? I don’t understand. Like I said in one of my previous posts you guys fix something and break something else at the same time. There is absolutely no quality control with your products here. |
|
|
| Reply #12
ZLM
1261 Posts |
Posted - 12/17/2018 : 21:46:05
|
| Sonicmixmaster, it seems your comport connection has some problems. Reconnect it and try again should work. |
|
|
| Reply #13
ZLM
1261 Posts |
|
| Reply #14
ZLM
1261 Posts |
|
| Reply #15
ikerrg
United Kingdom
334 Posts |
Posted - 12/18/2018 : 06:51:48
|
| @ZLM: Any improvement when handling the "55 AA 05 XX" codes in the memory to avoid the freeze when downloading? |
|
|
| Reply #16
ZLM
1261 Posts |
|
| Reply #17
ikerrg
United Kingdom
334 Posts |
Posted - 12/25/2018 : 10:46:42
|
Thanks ZLM. That version (2.57) finally seems to work properly! It downloaded the memory of my last plane trip and converted the data to .csv without problems. You can release version 2.57 in the official download link.
On the other hand, the data I just downloaded is from the latest plane trip I recorded using the M4011 tube selected (data here: https://www.dropbox.com/s/92psq2wg9qofdw0/PlaneTripData.zip?dl=0 ). There is something amazing that we never saw before. This is the first time I go through Heathrow’s security with the 500+V2 and the M4011 tube selected (last time I used the 500+V1 resulting in the M4011 tube to look totally saturated). Now, the M4011 counted more than 52 million counts in two consecutive seconds, probably even saturating the counting capabilities of the 500+V2. Whether those counts are real or amplified by the electrical noise inside the xray machine, I do not know, but I never saw such a huge count number! Any comments are welcome.
Image Insert:
50639 bytes
On the other hand, the flight data is quite nice, with a clear reduction in the count rate during the flight, that ullix will guess as a trip from north to south (LHR to MAD).
Image Insert:
80137 bytes
|
|
|
| Reply #18
ullix
Germany
1171 Posts |
Posted - 12/27/2018 : 04:32:22
|
The flight data truly are of textbook quality. If you don't mind, I would like to open a category of flight data on my GeigerLog site and include them there?
The X-ray machine's "count" data are nonsense. 50Mio counts means a dead time of under 20 nano-seconds. There is no tube with that ability. I doubt even the counters can count that fast. And then 2 consecutive seconds of each exactly showing 52 075 000. Never. I tried to write as a Hex, Oct, Bin number, but it also does not make sense. My guess is some interaction between X-ray and a memory cell in the counter.
Or perhaps a drone circling over the x-ray machine? These days, you can never be sure.
|
Edited by - ullix on 12/27/2018 05:50:07 |
|
|
| Reply #19
ikerrg
United Kingdom
334 Posts |
Posted - 12/27/2018 : 11:19:50
|
Sure, you are welcome to use the flight data as you prefer.
The security readings this time also make no sense to me. But it never happened before, although I previously recorded Heathrow's security using the SI3BG in the 500+V2. I think that number (52075000) must be the hardware limit for the number of counts the counter can count, but it does not correspond to any integer binary number (between 2^25 and 2^26). I wonder if the 500+V1 would exhibit the same behaviour. |
|
|
| |
Topic |
|
New firmwares (500/600) and data parse bug
