Almost all missing blue balloons during wardriving.

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

6 posts • Page 1 of 1
I've had this same problem on 4 different Moto phones for well over 2 years. (Pure version 3, two X4's, G4.) When I wardrive and display the map, very few blue balloons are displayed. Plenty of "beeps" are heard, indicating that Wifi's are being found, and later, when I upload the data, the wifis which were found appear on the map.
I have made modifications on the timings, and I wonder if those changes have led to this situation.
I find it hard to believe that nobody else sees this problem.
we've spent a significant amount of time trying to diagnose this issue in private communication. The following answers are provided to illustrate our debugging process and suggest new avenues for remediation. Note that none of the cases enumerated here are likely to respond to "app-side" fixes. This user remains the only report of this issue we've received.

The pins are managed by a 3rd party library - it shows as many as it can based on the available allowed app memory and its configuration. Neither that library, nor our implementation relating to it has changed in years, which indicates that any cause in subjective pin density is either 1. the configurations of the devices in use 2. the nature of the routes and networks visible to the app 3. changes to versions of Android in which a diminished number of pins is observed. As networks are still being detected, it seems safe to eliminate the scanning acuity of the application.

Case 1 scenarios:
low scan frequencies would cluster the displayed pins, make them appear infrequent - grouping or "aliasing" them together. While the point trilateration algorithm server-side could still distinguish and spread them back out (especially over multiple observations/sessions), they'd appear to cluster together too densely to distinguish individually in the application. This could also happen if the scan frequency was adjusted *upward* beyond the reliable radio switching period, although device overheating, inconsistent behavior, and unreliable scanning would likely also manifest at this speed. Radio damage, malware, contention for the radio, or memory exhaustion due to external apps could also result in this behavior, but that seems less likely to happen consistently on multiple devices.

Case 2 scenarios:
Patchy signal density could lead to pin "aliasing" - as could the globally increasing number of wireless networks in conjunction with scanning speed. If the number of networks observed slows the completion of the scan, pins could end up clustered too densely to distinguish. The global growth of wireless deployment in conjunction with the nature of the pin library also suggests that trails of pins might get physically shorter as the density of networks increases, since there will be more networks in close proximity (exhausting the total number displayed over a shorter distance)

Case 3 scenarios:
Android has made numerous changes to memory management, GPS and scanning acuity, and display updates over time. It's a continually evolving ecosystem, however the spread of devices on which the user reports this issue don't suggest any changes in the last year should be responsible, since not all devices should be running the same OS.
As with above, since the user states that the scanning acuity is not impacted, the OS-level change would have to correspond to a negative interaction with the pin-visualization library or with Google maps. The Google maps library is wholly independent of our app, and few changes have been made to our integration, but the maps library is a moving target, and in conjunction with hardware acceleration (especially on Samsung devices) is responsible for the lion's share of instability in our application. Apart from introducing optional "tile" layers to query server-side network-overlays and accepted the forced upgrades of the library, our integration has remained stable. If the tile feature is enabled, it might be a reasonable experiment to disable it and see if more pins are displayed. As noted, Android 9 (Pie) is a "lost" release for networks stumbling because of the scan throttling policy it introduced, and Android 10 *can* be configured with user interaction (in developer mode) to support pre-Pie-like scanning frequencies. Certainly Android Oreo (8), Nougat (7) and Marshmallow (6) devices are showing similar and consistent results for us over the years in which we've tested and developed the app, increasing density as mentioned in Case 2 notwithstanding. Pie can be tricked into scanning more quickly by split-screening with the Android "choose wifi" settings panel, as mentioned elsewhere in these forums.

In conclusion, the pins are and must be a "tail-dropping" queue - as new pins are added, old pins must be removed. The interactivity of the map, the application, and the device will always be inversely proportional to the number of pins displayed, and so mobile phones will have to prevent this list from growing without bounds. The pins can't serve as an unbounded "memo" of the route traveled since application launch without eventually exceeding the capabilities of the device. We have a feature in the works to help provide better route tracking per-run, but paying the bills, keeping the project going, and managing repeated support requests all take away from feature development time.

-ark
And to think, y'all do this for FREE.

Kudos for your stick-to-it-ness trying to make the client the best it can be.

#clientTheBestClient
Image
By default the map aggregates into circles with the number of networks found in them. If you want more icons to be shown on the map, tap on the 3-dots menu in the upper-right, and choose "Clustering Off", that will show individual pins per network.

Also tap on the magnifying glass and make sure that networks aren't being filtered from the map view in the "Filter Map" settings there.

As Arkasha says, memory is limited, so this will always show only the most recently found, between 128 and 1024 networks depending on how much memory is available: https://github.com/wiglenet/wigle-wifi- ... .java#L207

None of our test devices or any other users have reported anything amiss with regards to mapping icons, which likely means it's an issue with this user's hardware, configuration or expectations. Happy to be proven wrong with contradictory evidence.
-bobzilla - WiGLE.net just a little bit
Image
Pleased to say that we're releasing route display as a beta feature in the new 2.49 beta branch today- this will simplify the use case of seeing your route without the problems inherent in using the blue pins.

Both display and logging can be enabled for testing in the Settings menu under Map Settings.
100% rolled out now.

32894156 - hope this addresses your tracking needs (just enable display routes, unless you wanna preserve them for your own reference). this is waaaay more efficient than the pins in terms of display/data overhead, should work even on older phones.

I'll note that this *will* lose fidelity at very long route lengths/run durations - it will try and simplify the routes as best it can without losing important features - you'll note that unlike a lot of fitness trackers, we're really frank with you about how messy the GPS data is, but we simplify it for display as things get big so we can keep showing "where you've been"

sorry this has been a heavy lift, required significant re-plumbing.

-ark

6 posts • Page 1 of 1

Return to “WiGLE WiFi Wardriving Bugs”

Who is online

Users browsing this forum: No registered users and 2 guests