| Author |
 Topic  |
|
|
donghelan
Japan
65 Posts |
 Posted - 11/19/2018 : 05:13:04
|
Recently got this warning back from GMCMAP after submitting data successfully (including the wrong spelling ) :
Warrning! Please update/confirm your location.
What is the meaning? Are IP address based location checks or something in use now?
That can be very inaccurate, especially when VPNs are in use.
Excerpts from Geigerlog:
==== Updating Radiation World Maps ===============================
Successfully updated Radiation World Maps with these data:
CPM : 11
uSV : 0.07
UserID : 01734
CounterID : 7472099179
Website says:
Warrning! Please update/confirm your location.
OK.ERR0
==== Set Date&Time of Device =====================================
Date and Time from device is: 2018-11-19 21:05:54
Date and Time from computer is: 2018-11-19 21:06:24
Device is slower than computer by 30 sec
Setting device time to computer time
New Date and Time from device is: 2018-11-19 21:06:24
|
To bug or not debug, that is the Q |
|
| Reply #1
EmfDev
2260 Posts |
Posted - 11/19/2018 : 10:33:56
|
@donghelan,
You need to go to your GMC map device management profile and confirm/update your device settings. You don't need to change anything if nothing changed, just confirm. |
 |
|
| Reply #2
donghelan
Japan
65 Posts |
Posted - 11/20/2018 : 05:55:43
|
okido, done and solved. Thanks!
Needs to be done after a web application software update? |
To bug or not debug, that is the Q |
|
|
| Reply #3
EmfDev
2260 Posts |
Posted - 11/20/2018 : 10:40:55
|
| Nope. The server detected your location changed. |
|
|
| Reply #4
donghelan
Japan
65 Posts |
Posted - 11/20/2018 : 15:44:08
|
@emfdev,
I did not change anything. how could that happen? Set the Lat-Lon coordinates more than a month ago. |
To bug or not debug, that is the Q |
|
|
| Reply #5
donghelan
Japan
65 Posts |
Posted - 11/21/2018 : 09:22:14
|
quote:
Originally posted by EmfDev
Nope. The server detected your location changed.
It is annoying. Nothing changed but today again that stupid message appears.
Pushed edit button, did nothing but re-saved geiger counter details and the message disappeared.
Maybe that is why just few people use it after a while?
|
To bug or not debug, that is the Q |
|
|
| Reply #6
EmfDev
2260 Posts |
Posted - 11/21/2018 : 10:51:13
|
| Just ignore it. It's from the server. Sorry about that. |
|
|
| Reply #7
donghelan
Japan
65 Posts |
Posted - 12/01/2018 : 07:07:42
|
@emfdev The gmcmap is a conceptual mess as @Ullix expressed it quiet accurately in the geigercounter forum group recently.
- 1. It decides to insert timestamps on reception of data when it shouldn't.
Follow the common way i.e: The data format has to include date/time stamps that are sent by data loggers in this case geiger counters or data logging/data acquisition servers like geigerlog. The RTCs are not accurate enough on all devices for this unfortunately. When attached to a Data acquisition server or logging server, this can be corrected easily via NTP services.
- 2. It is not able to detect location changes correctly (especially when there are no).
- 3. It shows History data in UCT time correctly when user does not change it into local time but the header shows
Date (GMT-7:00) wrongly, minor issue but confusing the user.
- 4. It attempts to show CPM only which is currently giving the wrong sum value of CPM1st and CPM2nd from GMC500 devices.
Because I use geigerlog I can manipulate that value as being CPM1st only.
Other GMC500+ owners have to take the 2nd tube out to make CPM a valid value.
Of course this is also a minor issue when CPM2nd hardly adds any counts but imagine being close to a radioactive source - then it is a different more incorrect story.
If QCE wants to make this map more credible at least above 4 points need to be tackled. Ganbatte! do your best! |
To bug or not debug, that is the Q |
Edited by - donghelan on 12/02/2018 06:32:42 |
|
|
| Reply #8
EmfDev
2260 Posts |
Posted - 12/03/2018 : 14:53:04
|
1. But that way users can send fake data.
2. I think sending back time to sync if it's off is a better way, but we'll have to discuss.
3. Yes that one support said we're going to remove it.
4. Yes that one needs to change the code to change it to CPM1, and 2. We will see what we can do about it. |
|
|
| Reply #9
donghelan
Japan
65 Posts |
Posted - 12/05/2018 : 06:45:44
|
quote:
Originally posted by EmfDev
1. But that way users can send fake data.
2. I think sending back time to sync if it's off is a better way, but we'll have to discuss.
3. Yes that one support said we're going to remove it.
4. Yes that one needs to change the code to change it to CPM1, and 2. We will see what we can do about it.
Anything on that map can be fake data now. The time stamps could have been added to fake data.
Because there is no real validation nor moderation.
The map is now in test phase so allowing garbage seems fine to me.
If everything is in order including the exchange format a more intelligent automated validation will have to be in place.
Data uploading should also be over secured link, probably based on ssl with certificates or something if fake data are a concern.
The source will need a better verification to be able to participate as well. |
To bug or not debug, that is the Q |
|
|
| Reply #10
EmfDev
2260 Posts |
Posted - 12/05/2018 : 16:29:33
|
We are not responsible for the fake data being sent by the users as there is no way to verify which one is real right now as the URL for sending a data to the server is open and can be used by anyone.
As for the RTC, in the end, by syncing the NTP services to the local device, you would want that time to be recorded to the server which is the same as server time(with offset) right now but also correct the RTC in the local device. |
|
|
| |
Topic |
|
Update Location warning
