The driver should have been professional enough to know that the vehicle he was driving was unsuitable to be driven on that road.
Some people always want to blame other people for their mistakes.
How would he know? He came from another country with the truck and load. And here not every road is signalled for length or tonnage. By the time he knew he couldn't reverse. You can not reverse one of those things more than a few metres anyway.
Exactly! The map navigator gadget did a mistake. It guided to a gas station that no longer existed, for starters. They had wrong information and bad updates.
People have been driving large trucks around for decades. How did they manage before the days of sat-nav devices?
These things are aids to drivers, not something to blindly depend on without giving any thought to what you are actually doing and applying a bit of common sense.
I have Wifi Analyzer (farproc) version 3.9.11-L and it does *not* ask permission for Location. It only asks permission for Storage:
"App-machtigingen" = Apps Permissions "Opslagruimte" = Storage
(I have a Nexus 5X, Android 7.0, it has "App ops" built-in.)
Nope. WiFi Analyzer is a receive only (passive) sniffer/monitor program. It doesn't transmit. The various rules and regulatations are for transmit power and frequencies, and would not apply to a receiver. As long as the receiver meets incidental radiation (FCC Part 15) requirements which is handled by the maker of the tablet or cellphone. If someone wants to use WiFi Analyzer as a connection manager, the available transmit channels will be automagically limited by the tablet or smartphone firmware, not the application.
Looking at WiFi Analyzer, it will receive from Ch 1 to 14, which is well outside the US range of Ch 1 to 11. There is no country setting in the app settings.
That's changing. "In Android 6.0 Marshmallow, application will not be granted any permission at installation time. Instead, application has to ask user for a permission one-by-one at runtime."
Probably not as well. Using Google Maps on a trip these days is far superior to the old paper AAA TripTiks and routes inked on paper maps I once had to use. And of course AAA occasionally made mistakes too.
You give far too much credit to the human condition... 8-/
More details:
On 5GHz, WiFi analyzer looks at 16 channels at a time. There's a sliding window at the top of the screen to allow users to select which
16 channels to view. Looks like the end to end range is 5170 to 5815 MHz.Also, I goofed a little on how channels are selected. In the WiFi Analyzer settings, there are two pages for setting the available channels for 2.4 and 5GHz bands. The list appears to be pre-populated for US channels. I have no idea what will happen if the tablet is moved to another jurisdiction. It might be automatic, or it might be a manual ordeal filling out the proper channels. It might also be limited by the capabilities of the Wi-Fi radio.
The full list allows scanning from:
2.4GHz Ch 1 to 15 5GHz Ch 183 (4915MHz) to Ch 165 (5825Mhz)Drivel: I have my Linksys EA2700 router set to "auto channel" on
5GHz. There are only a few 5GHz routers in my neighborhood, so I would expect to find them evenly distributed among the available frequencies. That's roughly what I found when I started writing this rant. After about 10 mins, I find that all 4 of the visible systems, including mine, had moved and are now piled up near the top of the frequency range, including mine. That's all of them within a few channels of each other with plenty of overlap. Yet another Wi-Fi feature that doesn't work quite right.
Google made a rather big mistake in the Santa Cruz area. The 122deg longitude line goes through the middle of town. Everything to the west of 122deg was correctly based on WGS84. Everything to the east was based on NAD27. I never bothered to see how far east it extended. You could actually see the jog in satellite photos. Measuring the offset produced approximately a 200ft error, which is approximately what I would expect from the this mistake.
With such a clear cut and drastic error, one would expect Google to fix the problem fairly quickly. Nope. It took about 2 years to met to get their attention. I was only successful because at the time, a friend worked in the Google Maps group and crammed it into the queue for the price of a restaurant dinner for his family. I think it was about 2000 or maybe earlier and things undoubtedly have changed since then.
Around here, the gated "restricted entry" properties are usually pot farms.
I email everyone who plans to visit a map with the route inscribed: As one gets further up the hill, many of the roads shown on the map were either washed out, overgrown, undermined, planned but not built, or gated. A few end in a precipitous drop. It would be nice if the map makers added such designations. Maybe add pot holes, death traps, angry land owners, no turn-around, etc. I used to have a sign board at the transition between the county maintained road, and the owner maintained section, showing some of these hazards. It was a big help, but the tourists and visitors kept stealing the map. When someone stole the map and the sign board, I gave up.
I use Open Street Maps to generate routes and directions. (going away) I've made a few local corrections to the maps. Adding things is fairly easy. Removing them, such as deleting roads that don't exist, is almost impossible.
I forgot the main site, which also has A->B routing: Click on the arrow icon to the right of the search box "Go".
Maybe this will help:
My guess(tm) is: wifi only = Wild guess based on various inaccurate databases, geodata, IP location, etc. coarse = GPS only. fine = AGPS (assisted GPS) using location data from cell site.
There's also the Fused Location Provider: "...will blend data from GPS, cell tower triangulation, and
without your having to manually set all of that up."
I know. But the interesting channels to listen on vary depending on the country. Whether the application really knows and uses this information I haven't verified.
That's exactly what I said.
No, they did not. Not from that far. Actually, IIRC he came from a country that was in the Soviet Union in the past, so no way they could drive here till relatively recently. Very probably he could not read the text in the signposts, different language. Plus, there is always a first trip.
I'm sure he did.
I expect more from those paid with subscription devices.
I don't think AGPS is any better resolution than GPS, merely that it can get a fix quicker if the almanac is out of date by fetching it as data rather than waiting for it as satellite broadcast, or you've travelled a considerable distance with GPS disabled.
That is correct.
Knowing the approximate location and time, you can find out what exact satellites should be in view (from tables), and tune the receivers for those, instead of trying all.
Their dispatchers told them what routes to take. These days trucking companies use sat-nav devices to replace dispatchers, hoping to save money.
Cheers, -- tlvp
This is confusing that there are *four* location providers:
But only two types of location access permission: a. android.permission.ACCESS_FINE_LOCATION b. android.permission.ACCESS_COARSE_LOCATION
Namely:
The interesting point is that the results are indirect in that a *network lookup* from an existing database is what supplies the location.
And, notice that this network lookup *combines* the GPS location (fine access) with the results from the Google database of access point MAC address and/or cell tower ID number (coarse access).
In contrast, the passive location provider doesn't use your current GPS fix, so it just goes into the Google Database to look up the nearest access point MAC addresses and/or cell tower id numbers.
It would be nice if some of our European friends on this ng would install and test that WiFi analyzer to tell us how it works with the European
2.4GHz channels.On Sun, 25 Sep 2016 20:38:52 +0200, Carlos E.R. wrote:
It was interesting to see in that article that Jeff recommended that these permissions are not possible for the user to revoke from the app!
android.permission.ACCESS_LOCATION_EXTRA_COMMANDS android.permission.ACCESS_NETWORK_STATE android.permission.ACCESS_NOTIFICATION_POLICY android.permission.ACCESS_WIFI_STATE android.permission.ACCESS_WIMAX_STATE android.permission.BLUETOOTH android.permission.BLUETOOTH_ADMIN android.permission.BROADCAST_STICKY android.permission.CHANGE_NETWORK_STATE android.permission.CHANGE_WIFI_MULTICAST_STATE android.permission.CHANGE_WIFI_STATE android.permission.CHANGE_WIMAX_STATE android.permission.DISABLE_KEYGUARD android.permission.EXPAND_STATUS_BAR android.permission.FLASHLIGHT android.permission.GET_ACCOUNTS android.permission.GET_PACKAGE_SIZE android.permission.INTERNET android.permission.KILL_BACKGROUND_PROCESSES android.permission.MODIFY_AUDIO_SETTINGS android.permission.NFC android.permission.READ_SYNC_SETTINGS android.permission.READ_SYNC_STATS android.permission.RECEIVE_BOOT_COMPLETED android.permission.REORDER_TASKS android.permission.REQUEST_INSTALL_PACKAGES android.permission.SET_TIME_ZONE android.permission.SET_WALLPAPER android.permission.SET_WALLPAPER_HINTS android.permission.SUBSCRIBED_FEEDS_READ android.permission.TRANSMIT_IR android.permission.USE_FINGERPRINT android.permission.VIBRATE android.permission.WAKE_LOCK android.permission.WRITE_SYNC_SETTINGS com.android.alarm.permission.SET_ALARM com.android.launcher.permission.INSTALL_SHORTCUT com.android.launcher.permission.UNINSTALL_SHORTCUT
More interesting, perhaps, are these location permissions:
Where it seems that there are two location permissions, as we might imagine: android.permission.ACCESS_FINE_LOCATION android.permission.ACCESS_COARSE_LOCATION
Unfortunately, the caption of that screenshot says that if either one is granted, the other is also granted, automatically! "If any permission in a Permission Group is granted. \ Another permission in the same group will be automatically \ granted as well."
Thanks for checking up on this for us Jeff.
Given that it just "passively" scans for frequencies which include Europe and US channels, the WiFi analyzer basically shouldn't need location access, and, what's worse, the fact that it *asks* for location access, probably means that they "do something" with it (e.g., maybe they transmit it back to the mother ship?).
Why else would it ask if they didn't do something with it?
That will be a welcome sight when the apps have to ask *us* for "runtime permission" *when* they want them, and that we can say "no" for spurious permissions.
"In Android 6.0 Marshmallow, an application will not be granted any permission at installation time. Instead, an application has to ask user for a permission one-by-one at runtime."
Apparently, the developer has to *force* the dialog box to ask the user, otherwise, the app will just *not* get the requested information, and may crash (depending on how the app handles errors).
Apparently, from reading Jeff's recommended article, developers have two choices, depending on whether they "set" their targetSdkVersion to 23 and above, or 22 and lower.
If targetSdkVersion = 22 and lower, then the app will request permissions at install time; if targetSdkVersion = 23 and above, the app will get no permission at install time, and, instead, it has to ask for permissions at run time.
I suspect most developers will set it to target 22; but I would be pleasantly surprised if they set it to target 23!
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.