Related
a lot of smart/pda phones have a lot of memory. I was thinking if there's a way to enable a software-based call screening service. So, instead of calls going to voicemail they would go to a personalized answering machine on the phone.
do a search for answering machine or voice mail
seems some if not all htc devices cant control that part
of the gsm module from programs running on the pda
And other devices that can, like g-smart already have apps like this built in.
By the way these devices never have enough memory (at least not RAM) in my opinion.
Its a trade off. The ram is whats sucking the juice. Double the ram and perhaps your battery would not make it through the day. I think what we need is microsoft to take more advantage of "execute in place" memory in flash cards. If they allowed devices to be configured to run apps of this by the user then manufacturers would be selling more. Many cards are close enough to the speed of ram anyway.
I remember reading somewhere about a new kind of RAM, something magnetic that retains data without power but still works fast enough even for PC speeds.
It was planned to use this for PCs to eliminate boot time and data loss on power outages.
Haven't heard much more about it though.
I keep reading about problems with the radio not being compatible because the rogers radio is somehow different. What exactly is the radio? I'm betting it doesn't mean my phone will tune in to AM/FM stations....unless it does and makes me love my phone even more...lol
basically the phone radio controls your reception, with a newer radio you will usually get a better reception quality as well as GPS fix is faster.
the radio also controls how fast the camera is and a little bit of the quality(i don't know why i just know it's true
XwXDv8XwX said:
I keep reading about problems with the radio not being compatible because the rogers radio is somehow different. What exactly is the radio? I'm betting it doesn't mean my phone will tune in to AM/FM stations....unless it does and makes me love my phone even more...lol
Click to expand...
Click to collapse
In the context of phone hacking/hardware, the "radio" refers to the part of the phone which communicates with cellular towers. It is so named because the communication is done via radio waves. Specifically when people talk of flashing the radio, they are referring to the baseband processor. In most modern (2G and up) mobile phones, there are actually two processors. One is the application processor, which does all the work involving the operating system and apps. The other is the baseband processor, which actually deals with the GSM or WCDMA air interface (its a lot more complex than just broadcasting ones and zeros into the air).
Why would they use two processors instead of one? There are two main reasons. The first is that in order for cell networks to function properly, timing is key. For example, in the GSM system, each frequency is divided up into several time slots (TDMA means Time Division Multiple Access). The length of these slots are counted in the milliseconds. If a phone starts transmitting just a couple of milliseconds too late, it will overlap into the adjacent time slot and corrupt both its own and the neighboring transmission. Now, have you ever had your phone lag up because it was doing something complex? If the GSM stack ran on the same processor as the application stack, any system lagging introduced by the os/apps could cause the GSM connection to be unstable. The other reason is security. Especially in the age of smartphones, users are able to run code that may not be verified as secure. Separating the two functions prevents malicious code from tampering with the radio operations.
Note however that there are some flavors of Symbian which CAN run both the applications and baseband on the same processor. These are called real-time flavors of Symbian, so noted because the processor will always execute the baseband in real-time, regardless of how high apps are prioritized. This solves the timing problem, but other techniques have to be employed to add additional security.
As some of you may know I've ported the nvidia verson of the bcmdhd WiFi driver from their Tegra X1 reference kernel source code to xceed. What you all probably don't know is that there is a significant difference between nvidia's version, and the one in Google's kernel tree:
Nvidia's bcmdhd driver lacks an API called "GSCAN". What is GSCAN? GSCAN is an Android WiFi driver API for scanning for access points and making the list available to Android. Now you might say: but this works in xceed! Stop the bull, cheepskate, what are you talking about?
Yes, of course it works, because the "naked" bcmdhd driver implements a standard API for scanning for access points. So what is GSCAN really for?
Simple: it's meant to make the gathering of data about access points near your location as thorough and detailed as possible, in order to enable Google to create a mesh of these access points in order to improve their location service based on WiFi data. It's the infamous "Scan for access points even when WiFi is off" option in the Settings. And even if you turn that option off, while your WiFi is enabled so would be GSCAN, gathering data about access points and ruining your battery life.
I've deliberately left this API out of Xceed. First of all, this greatly improves battery life with WiFi. But to be fair to myself, it's not the only reason batterry life is so great: it took a substantial amount of hacking and insights to get to the point where xceed is now.
But secondly, and more importantly, this makes the users of my kernel completely black-boxed towards Google, and Google has no means to interfere with your own control of battery life, or the WiFi and therefore device itself in a manner that you do not condone. It is, really and truly, as much a political as a technical decision, and I intend to keep it that way.
I can only estimate, but if the WiFi drivers of other devices would have the GSCAN API removed (and please note that the WiFi and Android works just fine without it) the battery life would see a substantial boost.
I don't think this was a great decision by Google by any measure, at least from the consumer point of view. Let's hope that maybe in a future Android version it will be possible to turn it off completely without having to remove it from the driver. Does that sound likely? Rather not. But as always, one can hope.
And in the meantime, or for as long as you wish, there's xceed.
Have a nice day.
Very interesting. Would you care to speculate on why Google did this?
Do I understand correctly that GSCAN is a module in the bcmdhd driver that's always active, regardless of "Scan for access points even when WiFi is off"?
To my untrained eye it just looks like GSCAN is a mechanism that pushes the job of constantly polling for accesspoint away from the application processor and letting them firmware of the wifi do the work.
I can even imagine this might be more battery efficient.
How did you measure the effect on consumption?
smitel said:
Do I understand correctly that GSCAN is a module in the bcmdhd driver that's always active, regardless of "Scan for access points even when WiFi is off"?
To my untrained eye it just looks like GSCAN is a mechanism that pushes the job of constantly polling for accesspoint away from the application processor and letting them firmware of the wifi do the work.
I can even imagine this might be more battery efficient.
How did you measure the effect on consumption?
Click to expand...
Click to collapse
GSCAN does not run in the firmware but in the bcmdhd driver. Even if it did, it would be hardly more efficient than it not running at all.
cheep5k8 said:
GSCAN does not run in the firmware but in the bcmdhd driver.
Click to expand...
Click to collapse
It seems like this GSCAN functionality is called "Prefered Network Offload" (PNO) by Broadcom and is also used by Wi-Fi Location Service(WLS).
It offloads the wifi probing from Android to the Wifi firmware.
It seems implemented in dhd_pno.c, which gives commands to the Wifi firmware through dhd_iovar().
Even if it did, it would be hardly more efficient than it not running at all.
Click to expand...
Click to collapse
I can imagine using Wifi for localization requires a lot more data collection/probing than just using Wifi for connecting to networks.
Without kernel-support this would require Android to do a lot of polling and collection.
GSCAN seems an system to collect this data in kernel or in firmware, and produce it batch/event-wise to Android for consumption.
And it's also used for 'preferred network offload'. So it offloads/optimizes the probing for Wifi networks into bcmdhd or firmware instead of doing it through wpa_supplicant in userspace.
So this should also save battery.
Is your issue with the 'Wi-Fi Localization Services'?
I don't know if disabling GSCAN means Android will no longer use Wifi for localization.
If it does, maybe setting 'Location Mode' to 'Device only' would produce the same result?
If it does not, disabling GSCAN would increase power consumption because all the polling would require waking Android instead of just doing it in kernel or even firmware.
smitel said:
Are we talking about the stuff in https://android.googlesource.com/pl...ce4678bcb770359a632/bcmdhd/wifi_hal/gscan.cpp ?
GSCAN seems to get enabled at https://android.googlesource.com/pl...78bcb770359a632/bcmdhd/wifi_hal/gscan.cpp#464
Which does a createFeatureRequest(), which does a vendor-specific nl80211 command (NL80211_ATTR_VENDOR_DATA) to the driver.
Hmmm, which actually confuses me, because I thought I was looking at the part where the driver communicates with the Wifi HAL/Firmware.
Modern stuff is so incredibly layered.
This does speak a lot about how this stuff seems to be implemented on the wifi chip:
https://android.googlesource.com/pl.../+/master/include/hardware_legacy/gscan.h#319
Edit: I looked a little bit extra.
It seems like this GSCAN functionality is called "Prefered Network Offload" (PNO) by Broadcom and is also used by Wi-Fi Location Service(WLS).
It offloads the wifi probing from Android to the Wifi firmware.
Code:
// Therefore, it is acceptable for firmware to store a crc24, crc32 or other short hash of the SSID,
// such that a low but non-zero probability of collision exist. With that scheme it should be
// possible for firmware to keep an entry as small as 4 bytes for each pno network.
// For instance, a firmware pn0 entry can be implemented in the form of:
// PNO ENTRY = crc24(3 bytes) | flags>>3 (5 bits) | auth flags(3 bits)
//
// No scans should be automatically performed by the chip. Instead all scan results from gscan
// should be scored and the
I can imagine using Wifi for localization requires a lot more data collection/probing than just using Wifi for connecting to networks.
Without kernel-support this would require Android to do a lot of polling and collection.
GSCAN seems an system to collect this data in kernel or in firmware, and produce it batch/event-wise to Android for consumption.
I don't know if disabling GSCAN means Android will no longer use Wifi for location.
If it does, maybe setting 'Location Mode' to 'Device only' would produce the same result?
If it does not, disabling GSCAN would increase power consumption because all the polling would require waking Android instead of just doing it in kernel or even firmware.
Click to expand...
Click to collapse
That logic seems sound at first, but it's not what can be observed when GSCAN is disabled in the driver; Android doesn't do what you propose, but feel free to prove me wrong. The GSCAN part of the driver could always be added to nvidia's driver.
cheep5k8 said:
That logic seems sound at first, but it's not what can be observed when GSCAN is disabled in the driver; Android doesn't do what you propose, but feel free to prove me wrong. The GSCAN part of the driver could always be added to nvidia's driver.
Click to expand...
Click to collapse
What do you observe when GSCAN is disabled in the driver?
smitel said:
What do you observe when GSCAN is disabled in the driver?
Click to expand...
Click to collapse
I don't understand the question. What would I observe?
BTW it's 9 AM in the morning here, I'm just barely up. I should have waited before replying, I'm not really able to go into detail with you right now.
cheep5k8 said:
BTW it's 9 AM in the morning here, I'm just barely up. I should have waited before replying, I'm not really able to go into detail with you right now.
Click to expand...
Click to collapse
Same here. But it's a holiday here in the Netherlands, King's Day, so I have all day.
I'm just curious to either the mechanics to what you're claiming or measurements to support these saving.
Because to me it looks like you're just disabling Android-specific optimizations by porting the generic Linux driver to the Android kernel.
smitel said:
Same here. But it's a holiday here in the Netherlands, King's Day, so I have all day.
I'm just curious to either the mechanics to what you're claiming or measurements to support these saving.
Because to me it looks like you're just disabling Android-specific optimizations by porting the generic Linux driver to the Android kernel.
Click to expand...
Click to collapse
You've got a good point, and I've been only somewhat dismissive because of the early time of day, sorry for that in any case.
That's what I thought at first, too. But I'll get back with more detail this evening. Thanks for being inquisitive and observant, without peer review stuff would just not be that good
Ok, so, TTYL :good:
Hello,
I have a quite capable ThinkPad 8 tablet running Windows 10. I think it would make a superb Android tablet given its 1080p screen and 4 Gb RAM but did not manage to find the adequate release for it.
I have tried Bliss OS, Phoenix OS and Android x86 but none of them worked OK:
Bliss OS - no cellular data, no battery status
Phoenix OS - 75% chinese, 25% english, no cellular data
Android x86 - no touchscreen, no cellular data
My major concern is cellular data as I want to use the tablet for GPS navigation with Waze. Did anyone manage to find a good release to work with ThinkPad tablets build for Windows environment?
Thank you!
Hi, how did you enter bios to install OS?
Hi all, just picked up a Tab S5E today - love the screen, built quality etc. What I don't love is the Wi-Fi performance. I'm left very confused.
I installed Android 10 right out the box and did a clean reset - after which my link speed in Wi-Fi settings shows 86 mbps throughput. For reference, my other phones (Oneplus 5 - 3 years old and Oneplus 8 Pro both show 866mbps receive and transmit speed).
When right next to the router I get a max of about 150mbps, with an average of 80mbps on Speed Tests - This is the case whether holding the tablet or not. When about 5 metres away through a wall this goes down to 45-55 Average, in comparison both phones show around 280-330 average.
When right next to the router with my other phones I get my networks full download which is 550mbps.
I understood before purchasing that if holding the tablet in the bottom left corner when in horizontal position (camera on the left) you are likely to lose signal - potentially mitigated with using a case. However, by wrapping my hands round the left antenna, on average - the speed increases to around 150-170 - odd...
When attempting to put pressure on the antennas from both ends and firmly wrapping my hands around the tablet, I do not see any network connectivity issues relating to dropouts and the WiFi bars remain on 5.
Honestly not got a clue what's happening here, either who have decently fast connections don't big this up online, or this is just a weird hardware fault with my unit.
Pretty disappointed. If anyone has any advice / screenshots of their speed results higher than this - I would greatly appreciate this, in which case I will definitely pursue a replacement device. I can't accept that in 2020 a device cannot achieve full 5.8ghz WiFi speeds when directly next to the router.
There is nothing wrong with your device. The maximum WiFi speed on the Galaxy Tab S5e is around 160 to 180 Mbit/s. I didn't expect this either when I bought this model and it is also a major bummer for me.
The device supports 802.11ac, but unfortunately Samsung only put a single antenna into it which limits it to a single MIMO stream (on a 80 MHz channel that gives you theoretical 433 Mbit/s throughput, which of course no device will ever reach). I would expect something around 220 Mbit/s with this configuration, but somehow the maximum speed I get with this device is only around 160 to 180 Mbit/s. It is not only the speed that is bad, it is also the signal strength that is exceptionally bad compared to all my other devices.
Your phones and other devices probably have two antennas and support 802.11ac with 2x2 MIMO which gives you theoretical throughput of 866 Mbit/s and around 500 Mbit/s in practice.
Thank you for your reply. I just received a replacement unit and tested before updating to the Android 10 update. There was indeed something wrong with that previous device as the link speed shows 433mbps and I consistently got 280-295mbps download.
However, I just updated it to Android 10 - now it's completely gone again. Link speed 87mbps and downloads of 20-70mbps. This is most definitely a software issue which I'll be contacting Samsung about.
Matthius said:
Thank you for your reply. I just received a replacement unit and tested before updating to the Android 10 update. There was indeed something wrong with that previous device as the link speed shows 433mbps and I consistently got 280-295mbps download.
However, I just updated it to Android 10 - now it's completely gone again. Link speed 87mbps and downloads of 20-70mbps. This is most definitely a software issue which I'll be contacting Samsung about.
Click to expand...
Click to collapse
I also got a WiFi issue when upgrading to Android 10. My tablet was working perfectly before the update but now will not auto connect. I agree this must be a software issue.
I have just upgraded my tablet to Android 10 and the Wi-Fi speed maxes out at 60 Mbit/s. I'm thinking about selling my device again, this is unusable.
rndm42 said:
I have just upgraded my tablet to Android 10 and the Wi-Fi speed maxes out at 60 Mbit/s. I'm thinking about selling my device again, this is unusable.
Click to expand...
Click to collapse
All I can suggest is to create a bug report in Samsung members app. I did so over 10 days ago now and am awaiting a response. The more people that do so the better - a fix needs to be rolled out for this. Something's quite wrong with how the WiFi module is working after this update, probably driver related.
Has anybody tried wiping the cache partition in Recovery Mode? If that doesn't help back up your device and perform a Hard Factory Reset. That normally fixes any software issues.
iceepyon said:
Has anybody tried wiping the cache partition in Recovery Mode? If that doesn't help back up your device and perform a Hard Factory Reset. That normally fixes any software issues.
Click to expand...
Click to collapse
With both the tab s5e's I've had I had reset them both twice, and cleared cache in recovery.
This is definitely an issue brought about with the update considering Android 9 was absolutely fine network wise.
Matthius said:
With both the tab s5e's I've had I had reset them both twice, and cleared cache in recovery.
This is definitely an issue brought about with the update considering Android 9 was absolutely fine network wise.
Click to expand...
Click to collapse
In that case you may have purchased a unit from a bad batch.
iceepyon said:
In that case you may have purchased a unit from a bad batch.
Click to expand...
Click to collapse
I disagree, this is definitely a new problem that was introduced with the recent Android 10 upgrade. Samsung made the Wi-Fi signal "more stable" by limiting the modulation type to QPSK (MCS-2) instead of 256-QAM (MCS-9) which effectively caps it to 87,8 Mbit/s on a 80 MHz channel. Instead of 180 Mbit/s with Android 9 (which was pretty bad), users are now getting around 50 Mbit/s (which is incredibly bad).
Auto WIFI Reconnection problem
rfb813 said:
I also got a WiFi issue when upgrading to Android 10. My tablet was working perfectly before the update but now will not auto connect. I agree this must be a software issue.
Click to expand...
Click to collapse
My S5e won't auto-reconnect following the recent upgrade to Android 10. Also stutters and freezes for a while after restarting in various apps and settings. System software issues presumably.
rndm42 said:
I disagree, this is definitely a new problem that was introduced with the recent Android 10 upgrade. Samsung made the Wi-Fi signal "more stable" by limiting the modulation type to QPSK (MCS-2) instead of 256-QAM (MCS-9) which effectively caps it to 87,8 Mbit/s on a 80 MHz channel. Instead of 180 Mbit/s with Android 9 (which was pretty bad), users are now getting around 50 Mbit/s (which is incredibly bad).
Click to expand...
Click to collapse
Thanks for doing the research to find this out. This definitely explains exactly what I'm seeing.
Very disappointing as I was achieving fine speeds 290mbps or slightly higher prior to the update. Now WiFi on the whole is pretty poor in comparison.
Why was this done intentionally - it really makes no sense. Surely this must get reverted.
I just got an update this morning aimed at WiFi improvements
TheIntruder said:
I just got an update this morning aimed at WiFi improvements
Click to expand...
Click to collapse
I can confirm this update has fixed all issues for me. Normal 433 link speed when next to the router and the same WiFi download speed as on Android 9.
Since updating to Android 10, I started having issues with mesh wifi (I'm using Google Wifi). Same position and setup that used to work perfectly with Android 9, now the table starts disconnecting from Wifi and I have to reboot to reconnect. Anyone else has this issue?
I'm contemplating buying an S5e tablet (in Australia). Does the reduced speed of WiFi impact on any practical applications ? My internet cable subscription is for 50mbps. It used to be 100mbps, but I dowgraded on purpose, seeing no benefit for the cost. Even at 50mbps (practically 46) we have moments like today when both myself and my son are working remotely to different employers, while my wife us watching a video. I realise there could be apps which require more bandwidth, so I'm just curious what those might be.
ludoo said:
Since updating to Android 10, I started having issues with mesh wifi (I'm using Google Wifi). Same position and setup that used to work perfectly with Android 9, now the table starts disconnecting from Wifi and I have to reboot to reconnect. Anyone else has this issue?
Click to expand...
Click to collapse
That is exactly my problem as well. Google WiFi and random disconnects from the tablet that sometimes get fixed by disconnecting/reconnecting but majority of the time a restart is the way to solve it.
No other device in the household gets disconnected from the network (neither was the tablet before upgrading) so it is definitely the update to blame.
Having similar issues following the update. I tend to turn the tablet off when I'm not using it, and thus far I have yet to successfully connect to WiFi on startup. I have to manually toggle WiFi to get it back on.
Same wifi issue here after updating to Android 10. Is there a way to manually update using file some were receiving in late July?
I am really bothered by this GROSS limitation too! It makes issues with the driver even worse.
Maybe our answer can be found on this page or something or nothing ?
https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qcacld-3.0/