In terms of external antennas, users have proudly showed us external antenna mods they've built for their phones - tends to void the warranty. There's no "drone" mode for WiWiWa right now, but pull requests would be very welcome. We'll note that Kismet's protocol is a great standard for this sort of...

some phones just stumble better! especially in the case of the Android Pie release, which will always be bad at scanning by design.
I'd recommend building a warPi and stuffing it into the trunk or a body panel, so they never have to see it.

Yeah - we've been discussing maybe adding some external USB/BT device support with this recent Pie/Q scan mess, but fundamentally, we use the OS-based facilities so we can list in the Play Store. What we've done to support WPA3 in current code: https://github.com/wiglenet/wigle-wifi-wardriving/searc...

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!

-ark

it all depends on when Android started reporting it as WPA3!

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

giving this a bump, since we can't upload it ourselves!

bluetooth is still a new feature, but its on the stats page; you just need to sort by the header!

we'll add it into the client soon.

cheers,

-ark

Two options:
1. export the old database from the old phone and put it onto the new phone (gets *everything*)
2. you can get your list of nets, but not the observations as an authenticated using "Database" -> "Import Observed"

We'll keep digging in; the call we use certainly sounds like it's prone to odd behavior: https://developer.android.com/reference/android/location/Location.html#getTime() In the most recent API, it sounds like we have some other options to get time: https://developer.android.com/reference/android/os/...

check your notifications - there's usually a "log in to <wifi net name>" pending that you can tap (or maybe things are just broken).

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 ...

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 tim...

if you "swipe" the screen, you take over positioning control. You can tap the reticle icon (the crosshair) to re-establish dynamic updates, or switch tabs and switch back to maps to resume updates. This is a common ui convention, since otherwise you'd end up fighting the GPS when you wanted to explo...

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 sho...