strange 'lastseen' issue

Issues with the Android network detection software. Please include Software version, Android version, and device when reporting

11 posts • Page 1 of 1

Postby jamesmurphy746 » Thu Jun 06, 2019 9:12 am

Using the Wigle android app, all standard. Went out on a trip last night and planned to re-visit a particular network.. came back eager to see the results and I notice according to my map I didn't see it on this particular run.. but it's not the first time that's happened so to try and work out what's going on I've been clearing the wigle db on my device before each run (after I back it up of course) so this time I opened up the db and see that the wifi IS there so it WAS seen [given the db was emptied]..

After a lot of digging in the PHP it's lead me to the 'lasttime' column.. the data seems strange.. [see attached image]

I see what looks like epoch time starting 1559755.....
I see 0, that could be fail for some reason.. ok..

..but the ones starting 940440....., don't understand those values.. is it a bug\error? I suspect this is messing up date comparisons..?

Postby jamesmurphy746 » Thu Jun 06, 2019 9:54 am


well, I guess it's not a bug as such as when I search the SSID on the wigle site the last seen date is what I expected it to be.. [has updated]

so, there seems to be two different 'methods' for storing date/time..

clearly the ones starting 1559755 are Unix epoch time in milliseconds

the ones starting 940440.. though, what are these? they're not epoch in seconds.. why use two different methods at the same time?

Postby arkasha » Thu Jun 06, 2019 2:36 pm

it looks to me like you have a GPS chip that reports "high" accuracy (GPS relies on accurate clocks) in spite of bad fixes. In this case, your chipset seems to have an affinity for the year 1999 (that's probably the year in which its design or parent design was initiated), and the chip or driver should be doing sanity checks but isn't. Those timestamps come from GPS, so individual device behavior will vary. It's also possible your GPS chip is just a fan of Prince, and chooses to "Party Like it's 1999" when idle, which I can respect.

Postby jamesmurphy746 » Thu Jun 06, 2019 9:06 pm

hmm, so.. the time coming from the gps receiver is not reliable.. can we have an option to use the system time instead? we're a lot more likely to notice the system time is wrong, he he.

this seems to happen on 3 out of 4 of my regular devices.. and to top it off the only device which DOES record epoch time is THE one which for some reason doesn't even detect 1/4 of the networks the other devices do.. that seems to be crummy luck.. 3/4 of my devices suffer this issue.. makes anything to do with date/time useless :(

Postby arkasha » Thu Jun 06, 2019 9:17 pm

the intended behavior is it "get correct" in the aggregate (both locally on server-side). individual measurements may be broken, but over time it gets more accurate. Bouncing off of buildings, temporary weather issues, and GPS failures all factor out over time. Since you're clearing your DB each time, you're snapshotting whatever data was logged *only* that time, effectively turning the network table into a series of disjoint observation tables. Network should get better and better with time, and the WiGLE database does a bit of post-processing on upload as well. That being said, WiFi Wardriving is open-source, and you can change the policy for your local version, or replace it with system time - it's just a different use case than the one we're optimizing for in the production client.

Postby arkasha » Thu Jun 06, 2019 9:19 pm

when looking through these observations, check the accuracy scores; it might be these are self-reporting errors, but the "generational" pattern of your DB replacement use-style is just keeping them from being replaced.

It's also fair to say that if the GPS clock value is that wrong, the position is almost certainly wrong as well; those satellites would be elsewhere in 1999.

Postby jamesmurphy746 » Sat Jun 08, 2019 7:36 am

Confirmed. Two nexus 7's and a Huawei mobile phone all have same issue, wrong date\time being recorded by Wigle. I'm quite shocked tbh, can't seem to find any information about this issue even though 3 of my devices encounter it.. accuracy does not seem to be affected [more than usual anyway] when I go out to an area and plot positions on the map, they're where I expect them to be..

I'm not clever enough to modify the android app to use the system time instead of time from GPS, but if 3 out of 4 of my devices are recording the wrong time surely I can't be that unlucky.. this surely is effecting others too..?, maybe they aren't aware.. it's not immediately obvious anything is going wrong unless you look at the data in detail.. any chance of an app update to add the option to calculate epoch time from system time instead?

For now, I've learnt how to make up a value for a certain date.. I will have to manually "fix" 3 databases after each run.. bit of a P.I.T.A to be honest.. any help appreciated. :wink:

Edit: just thought.. why not compare the two times GPS/System.. and if they're massively different.. there's some sort of issue.. let the user know there's a problem and maybe ask the user which, if any are correct and use those values for the session..?

Edit2: Aaah, I think I may have found a potential explanation: ... poch_ends/

I know the nexus are old but I only got them recently since they were cheap and I'm fully aware of what Google is up to with Pie regarding wifi scanning so they won't be getting any money off me right now.. he he

Edit3: I'm starting to get over my head here but further reading suggests 19.7 years [1,024 weeks] is a key 'date' with this gps update malarky .. 19.7 years ago it was 1999 [and yeah, was a great time for parties, he he].. we have a correlation I believe.. So definitely seems to be because I'm using an older device.. but maybe it's just me getting old but I prefer using devices from before the big companies started going overboard with restrictions, lol

So, do you think there's any chance of a work-around for this? If I've understood it right, It's always going to be 19.7 years [1,024 weeks] out [until the next time they change it anyways, he he] ;)

Fully appreciate this is not a bug with Wigle now, so feel free to move topic elsewhere. Seems to be a big 'thing' though.. wondering how many others are effected.. curious as to how many other uploads [from other users] have same issue..? [my recent uploads I did will be skewed as I always send you the raw data].. I'm guessing since 1999 was mentioned and you didn't instantly pick up on it - you didn't know..?[which is totally understandable given it's only a recent event and only effects "older" devices and nobody would know unless they looked really close] in which case I appreciate you might be a little busy now :wink:

Postby arkasha » Sat Jun 08, 2019 3:59 pm

We'll keep digging in; the call we use certainly sounds like it's prone to odd behavior: ... #getTime()

In the most recent API, it sounds like we have some other options to get time: ... imeClock()

Postby jamesmurphy746 » Sat Jun 15, 2019 8:15 am

saw there was an updated apk without any changes to the change logs.. hopeful it was a fix for wrong date\time I updated my devices.. No fix for wrong date\time but now my devices are scanning Bluetooth despite the fact I have Bluetooth scanning turned off...?

Postby arkasha » Sat Jun 15, 2019 5:05 pm

we'll look into it right away. can you try toggling bt scanning to see if that fixes the problem?

Postby arkasha » Mon Jun 17, 2019 1:12 am

We had updated WiWiWa to default to BT scanning "on" now that the feature is out of Beta - but we'd failed to update the default checkbox state. toggling it on and off again will fix the issue in the current release, and we've built a patch for the next one. Thanks for the bug report!


11 posts • Page 1 of 1

Return to “WiGLE WiFi Wardriving Bugs”

Who is online

Users browsing this forum: Theusu5k and 1 guest