Well, my goal for the upcoming v2.0 of my aGPS Patch is to bring support to five more devices. This is one of the devices I selected!
I'm looking for some testers to see if the patch will effectively work.
It simply replaces gps.conf in /etc/ to be much better performing.
You can download v1.3 by clicking here.
To install, use Root Explorer or ES File Explorer to copy the new one over. Reboot. Give GPS a try! I recommend GPS Status. If your device uses ClockWork Recovery, you can simply flash the ZIP.
A reference thread can be seen at http://forum.xda-developers.com/showthread.php?t=1250226.
Also, I'd love for someone to send me the gps.conf currently on their device.
Thank you for assisting me in the determination if this version works.
trying now!
-
taking it on the road, i'll post back
wha...? What's your basis for making such radical additions to gps.conf? And documentation as to why?
Even Nexus S gps.conf is only 6 lines of code!
Rrryan2 said:
wha...? What's your basis for making such radical additions to gps.conf? And documentation as to why?
Even Nexus S gps.conf is only 6 lines of code!
Click to expand...
Click to collapse
My basis was a faltering GPS on my two devices and got sick of waiting forever for locks and/or loss of locks while traveling.
I've discussed the as to why plenty of times. There are a number of variables that some chipsets have available for better and faster aGPS locks.
Also, the stock gps.conf for every device thus far has failed to align pools and xtra servers for best performance. I do that based on results of some scripts I made on one of my Linux servers. So, I adjust them according to response times.
A lot of custom ROM's forget about variables and support that some phones needed. So, I put them back in. If the variable is not used on a particular model, it will be ignored by the GPS unit.
And, I'll be making a big surprise boost for everyone's performance in two releases.
That's all I have to say, my press secretary will be glad to answer your questions. By that I mean I will be answering more questions as always.
tried it out yesterday on my way to work.
took under 30 seconds to lock every time.
it took about a minute or two to 'warm up' to me driving but once it did, it was down to 1m accuracy which i've never gotten before on any of my captivate devices
on this device, i've never even had lock!
very nice! more people need to try!
downloaded, installed, and testing.
Read other forum. Looks promising! I have the first build 1007, which is known to have major issues. CM7 (as of April) and every other ROM I have tried never improved accuracy. I have tried every modem up to two months ago (stopped using i9000 ROMs). There was a i9000 modem that improved locks, but it hindered wifi/radio. Since the chips are atop one another I assumed that the issue is hardware specific, with modem formware simply changing power sharing and static interference.
I will install and see if it works after it gathers some location info for a while.
Edit: Can I simply backup and then replace my original gps file in /etc folder with yours? Thanks!
I installed it, seemed to lock faster but did not see any improvement in the accuracy, I am running CM7 latest nightly build. With the modified file it got a fine location lock faster but then it jumped around a lot. I tested it using a Adobe Air mapping application I built for GIS mapping.
snowake said:
Edit: Can I simply backup and then replace my original gps file in /etc folder with yours? Thanks!
Click to expand...
Click to collapse
You can do that, sure thing!
quick6black said:
I installed it, seemed to lock faster but did not see any improvement in the accuracy, I am running CM7 latest nightly build. With the modified file it got a fine location lock faster but then it jumped around a lot. I tested it using a Adobe Air mapping application I built for GIS mapping.
Click to expand...
Click to collapse
What do you mean by jumping around? I do know that CM7 nightlies have had some problems with GPS lately. They removed some important code to let aGPS work properly. I'm not sure that could explain jumping around though.
My indicated accuracy was bouncing from 16 to 65 feet on GPS Status program. that may be what he meant by jumping around?
First lock was 14sec though.
Haven't been able to drive around yet to try much more than a quick look.
Running CM7 with nightly 123
The good news is it didn't seem to do any damage, everything still works at least about the same as before.
FireRaider said:
My indicated accuracy was bouncing from 16 to 65 feet on GPS Status program. that may be what he meant by jumping around?
First lock was 14sec though.
Haven't been able to drive around yet to try much more than a quick look.
Running CM7 with nightly 123
The good news is it didn't seem to do any damage, everything still works at least about the same as before.
Click to expand...
Click to collapse
Jumping occurs when a specific sat goes in and out. I get that in my flat with my case on. Otherwise it levels out between 9 & 13 ft.
If anyone can test with a different ROM and kernel?
Sent from my HTC Desire HD A9191 using XDA App
Care to explain a little more about how this AGPS patch helps?
I don't know how new you are to the Captivate world, but we've had countless threads around here about GPS performance.
AFAIK, all of these "tweaks" are really just messing with the AGPS settings, and at VERY most all that will do is slightly increase TTFF (time to first fix). It won't have any impact at all on tracking or strength of lock. And further, DaG a long while back basically ran through every piece of opensource/publicly configurable settings that exist on the Captivate. And through a whole bunch of research and discussing, it was decided that properly configuring your device to use the AT&T GSM spec-conforming AGPS system was the best thing to do.
So how exactly does your "patch" compare to that? And sorry if you find this a bit abrasive, but again, there has been over a year of "miracle fixes" that tend to do not a whole lot...
Shammyh said:
Care to explain a little more about how this AGPS patch helps?
I don't know how new you are to the Captivate world, but we've had countless threads around here about GPS performance.
AFAIK, all of these "tweaks" are really just messing with the AGPS settings, and at VERY most all that will do is slightly increase TTFF (time to first fix). It won't have any impact at all on tracking or strength of lock. And further, DaG a long while back basically ran through every piece of opensource/publicly configurable settings that exist on the Captivate. And through a whole bunch of research and discussing, it was decided that properly configuring your device to use the AT&T GSM spec-conforming AGPS system was the best thing to do.
So how exactly does your "patch" compare to that? And sorry if you find this a bit abrasive, but again, there has been over a year of "miracle fixes" that tend to do not a whole lot...
Click to expand...
Click to collapse
For those having issues with bouncing or a range in error on devices... I would recommend trying the "alternate world patch" to see if that alleviates the bouncing assuming it's related to a glitch in some GPS units.
Yes, I use the similar tactics in the gps.conf. AT&T, and WWE ROM's, typically don't have a fully configured gps.conf. I added variables that are actually supported. However, I plan to drop some variables because they only assist with older devices and not many of us keep those around when we can upgrade again.
Also, I use my co-located Linux servers to monitor NTP pool and XTRA server response times. I modified to get the best all-around attainment that way.
I don't know of these other people and have not seen their patches. I have had over 30,000 downloads and not even 2% negative response. Those who get grumpy failed to follow directions and are resolved one they are pointed back to the notes section or something like that.
I'll be introducing a "surprise" in v3.0 and that won't be discussed until it's time. I've had my work ripped by a lot of people and "slightly" modified without giving credit. I'd like to keep this one under wraps as best as possible.
crypted said:
You can do that, sure thing!
What do you mean by jumping around? I do know that CM7 nightlies have had some problems with GPS lately. They removed some important code to let aGPS work properly. I'm not sure that could explain jumping around though.
Click to expand...
Click to collapse
I was following it on a map and the gps marker was jumping around maybe 15-20 feet around my real location. It was jumping east to west as time progressed, kept the gps active for maybe 60 seconds. With the stock gps file as the accuracy increased the gps marker which was south of my real location, slowly moved north in small increment.
quick6black said:
I was following it on a map and the gps marker was jumping around maybe 15-20 feet around my real location. It was jumping east to west as time progressed, kept the gps active for maybe 60 seconds. With the stock gps file as the accuracy increased the gps marker which was south of my real location, slowly moved north in small increment.
Click to expand...
Click to collapse
If I understand you correctly, it's jumping and off-base when it's patch and when it's stock. If that is true, this lends credence to reports that CM has messed up the aGPS capabilities. Seems to be a standard issue the past few days with their latest builds. Luckily, a user dug into it for me and showed the code issues where CM is messing up by not allowing aGPS to function.
Let's hope they fix it!
crypted said:
Also, the stock gps.conf for every device thus far has failed to align pools and xtra servers for best performance. I do that based on results of some scripts I made on one of my Linux servers. So, I adjust them according to response times.
Click to expand...
Click to collapse
Your understanding of how pool.ntp.org works seems incomplete. 0.pool, 1.pool etc. point to random sets of servers that change hourly. As such, you can't just "align" them based on response and expect to get reliable, reproducible improvement going forward.
Xtra.bin is not used on the Captivate and is not ever downloaded. Even if you manually download it, it just gets discarded as corrupted. In any case, lto2.dat (valid for 7 days) > xtra.bin (24 hours).
A lot of custom ROM's forget about variables and support that some phones needed. So, I put them back in. If the variable is not used on a particular model, it will be ignored by the GPS unit.
Click to expand...
Click to collapse
Here's the complete stock gps.conf from the Samsung Nexus S, an 'AOSP' device that's a close relative to the Captivate and uses the same Broadcom BCM4751 chip:
Code:
NTP_SERVER=north-america.pool.ntp.org
XTRA_SERVER_1=http://xtra1.gpsonextra.net/xtra.bin
XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin
XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin
SUPL_HOST=supl.google.com
SUPL_PORT=7276
Rrryan2 said:
Your understanding of how pool.ntp.org works seems incomplete. 0.pool, 1.pool etc. point to random sets of servers that change hourly. As such, you can't just "align" them based on response and expect to get reliable, reproducible improvement going forward.
Xtra.bin is not used on the Captivate and is not ever downloaded. Even if you manually download it, it just gets discarded as corrupted. In any case, lto2.dat (valid for 7 days) > xtra.bin (24 hours).
Click to expand...
Click to collapse
Thanks for the input. Not having the device, I did not know the bin was out of the running. That's why I started the thread!!!
As far as pools, I'll check into that more thoroughly. I'm not in full agreement, but 24 hours of logging nslookup may change that and prove your point.
crypted said:
As far as pools, I'll check into that more thoroughly. I'm not in full agreement, but 24 hours of logging nslookup may change that and prove your point.
Click to expand...
Click to collapse
From http://www.pool.ntp.org/en/use.html :
"The 0, 1 and 2.pool.ntp.org names point to a random set of servers that will change every hour."
What's not to agree with?
24 hours of lookup logs to randomly assigned servers will be exactly that, and won't be able to predict what performance will be like over the next 24 hours of randomly assigned server groups.
Here's a quick dump of a few pings to 1.pool.ntp.org conducted just a few minutes apart:
Code:
>ping 1.us.pool.ntp.org
Pinging 1.us.pool.ntp.org [204.9.136.253] with 32 bytes of data:
Reply from 204.9.136.253: bytes=32 time=365ms TTL=50
Reply from 204.9.136.253: bytes=32 time=363ms TTL=50
Reply from 204.9.136.253: bytes=32 time=356ms TTL=50
Reply from 204.9.136.253: bytes=32 time=346ms TTL=50
Ping statistics for 204.9.136.253:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 346ms, Maximum = 365ms, Average = 357ms
>ping 1.us.pool.ntp.org
Pinging 1.us.pool.ntp.org [67.18.187.111] with 32 bytes of data:
Reply from 67.18.187.111: bytes=32 time=307ms TTL=48
Reply from 67.18.187.111: bytes=32 time=210ms TTL=48
Reply from 67.18.187.111: bytes=32 time=102ms TTL=48
Reply from 67.18.187.111: bytes=32 time=156ms TTL=48
Ping statistics for 67.18.187.111:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 102ms, Maximum = 307ms, Average = 193ms
>ping 1.us.pool.ntp.org
Pinging 1.us.pool.ntp.org [173.193.227.67] with 32 bytes of data:
Reply from 173.193.227.67: bytes=32 time=687ms TTL=46
Reply from 173.193.227.67: bytes=32 time=573ms TTL=46
Reply from 173.193.227.67: bytes=32 time=638ms TTL=46
Reply from 173.193.227.67: bytes=32 time=705ms TTL=46
Ping statistics for 173.193.227.67:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 573ms, Maximum = 705ms, Average = 650ms
Note that 1.us.pool.ntp.org resolves to a different IP each time, and avg. ping times vary accordingly. An hour from now, it will resolve to a different set of servers/IPs.
Arranging 0.pool, 1.pool etc. into some arbitrary order isn't going to accomplish anything.
Rrryan2 said:
From http://www.pool.ntp.org/en/use.html :
"The 0, 1 and 2.pool.ntp.org names point to a random set of servers that will change every hour."
What's not to agree with?
24 hours of lookup logs to randomly assigned servers will be exactly that, and won't be able to predict what performance will be like over the next 24 hours of randomly assigned server groups.
Here's a quick dump of a few pings to 1.pool.ntp.org conducted just a few minutes apart:
Code:
>ping 1.us.pool.ntp.org
Pinging 1.us.pool.ntp.org [204.9.136.253] with 32 bytes of data:
Reply from 204.9.136.253: bytes=32 time=365ms TTL=50
Reply from 204.9.136.253: bytes=32 time=363ms TTL=50
Reply from 204.9.136.253: bytes=32 time=356ms TTL=50
Reply from 204.9.136.253: bytes=32 time=346ms TTL=50
Ping statistics for 204.9.136.253:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 346ms, Maximum = 365ms, Average = 357ms
>ping 1.us.pool.ntp.org
Pinging 1.us.pool.ntp.org [67.18.187.111] with 32 bytes of data:
Reply from 67.18.187.111: bytes=32 time=307ms TTL=48
Reply from 67.18.187.111: bytes=32 time=210ms TTL=48
Reply from 67.18.187.111: bytes=32 time=102ms TTL=48
Reply from 67.18.187.111: bytes=32 time=156ms TTL=48
Ping statistics for 67.18.187.111:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 102ms, Maximum = 307ms, Average = 193ms
>ping 1.us.pool.ntp.org
Pinging 1.us.pool.ntp.org [173.193.227.67] with 32 bytes of data:
Reply from 173.193.227.67: bytes=32 time=687ms TTL=46
Reply from 173.193.227.67: bytes=32 time=573ms TTL=46
Reply from 173.193.227.67: bytes=32 time=638ms TTL=46
Reply from 173.193.227.67: bytes=32 time=705ms TTL=46
Ping statistics for 173.193.227.67:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 573ms, Maximum = 705ms, Average = 650ms
Note that 1.us.pool.ntp.org resolves to a different IP each time, and avg. ping times vary accordingly. An hour from now, it will resolve to a different set of servers/IPs.
Arranging 0.pool, 1.pool etc. into some arbitrary order isn't going to accomplish anything.
Click to expand...
Click to collapse
No worries. I may just make my own pooling! I'm prone to do stupid things like that with my time.
Should stock gps settings be used?
(standalone, www.spirent-lcs.com, 7275)
Or
(ms based, supl.google.com, 7276)?
Here is captivates stock gps.conf
NTP_SERVER=north-america.pool.ntp.org
XTRA_SERVER_1=http://xtra1.gpsonextra.net/xtra.bin
XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin
XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin
Click to expand...
Click to collapse
Related
Has someone tried the real bluetooth speed , for example when connected to internet throught BT internet sharing ?
'cos it's not clear if this device has full BT2.0+EDR speed ( 3 mb/sec about 150Kbytes/sec ) or it's simple 2.0 not EDR ( 750 kb/sec , about 50 Kbytes/sec ).
It's a simple test , you need an usb 2.0+EDR dongle , estabilish a connection throught BT internet sharing ( be sure you are in HSDPA area ) and check your data speed downloading a large file , you can see your downloading data rate ( average ) into the standard Internet explorer download window...
Can someone try this ? I'm interested on this device but need to know also this feature....
THX
Vdavide
My guess is that it will be BT 2.0+EDR but then again I don't own a HTC TC.
According to PDADB it comes with Bluetooth 2.0 not the EDR version
I am connected to the internet via orbitII and bluetooth. ~110KB/sec
Hope that helps
It's 2.0 EDR.
Checked it on my HP Notebook and first it had been connected with a max speed of 700Kbit/s. As my notebook should be EDR-ready I checked drivers and found out that these weren't EDR-capaple. So I installed new driver from the successor and now I'm connected with 2,1Mbit/s
Rongara said:
It's 2.0 EDR.
Checked it on my HP Notebook and first it had been connected with a max speed of 700Kbit/s. As my notebook should be EDR-ready I checked drivers and found out that these weren't EDR-capaple. So I installed new driver from the successor and now I'm connected with 2,1Mbit/s
Click to expand...
Click to collapse
nice, thanx
nice infos , thx to all!
Nice, good to know it does have EDR I'm going to mail PDADB about it so that they change it.
pardon my ignorance of the Bluetooth protocols, but I don't understand how 3 mega BITS per second could equate to 150 kilo BYTES per second - in the version of computer science I learned, 8 bits equal a byte, meaning 3 mb/s equates to more than 350 kB/s
even if we allow a massive 30% protocol overhead, 350 kB/s still has about 250 kB/s usable bandwidth
I'd appreciate it if someone knowledgeable in BT could shed some light on this
lol, it is much faster copying things to the Touch Cruise using HSDPA (3.6 megabit = 450 kbyte/s), than using the Bluetooth connection (150 Kbyte/s).
tandy279 said:
pardon my ignorance of the Bluetooth protocols, but I don't understand how 3 mega BITS per second could equate to 150 kilo BYTES per second - in the version of computer science I learned, 8 bits equal a byte, meaning 3 mb/s equates to more than 350 kB/s
even if we allow a massive 30% protocol overhead, 350 kB/s still has about 250 kB/s usable bandwidth
I'd appreciate it if someone knowledgeable in BT could shed some light on this
Click to expand...
Click to collapse
3Mbit is a theorical speed ... for each byte there are some extra bit for protocol handling ( almost 8 bit + 1 start bit + 1 stop bit , error control and so on ) ... and if you give a try you will get the speed reported in the first post ( that are proven , not theory ... ).
vdavide
3Mbit is a theorical speed ... for each byte there are some extra bit for protocol handling ( almost 8 bit + 1 start bit + 1 stop bit , error control and so on ) ... and if you give a try you will get the speed reported in the first post ( that are proven , not theory ... ).
vdavide
Click to expand...
Click to collapse
Using less words:
3Mbit = Marketing hype.
Noam23 said:
Using less words:
3Mbit = Marketing hype.
Click to expand...
Click to collapse
this ia why people was waiting for a software like WMwifirouter ... using wifi the speed reach about 300Kbytes from device to PC when in hsdpa coverage
Friends,
Since my first HTC phone I have, probably like the rest of you, either ticked off header compression and left software compression unchecked either because of something I googled or because some connection setup wizard made the decision for me. I've grown increasingly curious about this and bam here's a thread.
Presuming that any form of bandwidth compression would buy me more throughput, would that not come at the expense of additional CPU and battery to do the math? Would any additional throughput due to "software compresson" and or IP header compression be contigent on the type of data being transmitted (for example a thoroughly compressed file versus a big white BMP or the letter X a million times)? In addition to my own eccentric fascination with this, I do like to listen to Howard on SiriusWM5 and I'd like to know whether or not to check these boxes for the sake of my battery life and for the sake of being able to get the "CD quality" stream without it chopping up and buffering.
So I just did a little field testing on my Fuze running ROMeOS 1.70.3 (CE 21009) with radio 1.08.25.20, 100% signal in midtown Manhattan (near where that plane's taking a bath) at midnight EST with nothing but WMWifiRouter running for tethering with wifi power on full blast using multiple speedtest providers like dslreports.com/speedtest and speakeasy.net/speedtest both to NYC servers and to others across the country with no compression five times, header compression five times and header and software compression five times.
But the results are inconclusive. Without any compression I get an average of 1200Kbs/900Kbs, max 1339Kbs/1346Kbps. With both types of compression I got slightly slower download and slightly faster upload (1120Kbs/1427Kbs max). Probably not enough sample data not to chalk that discrepency up to an anonomly.
Back in my Kaiser days, I was able to break 2200Kbps without compression both on these speedtests and on very large tethered downloads. And now during the day I get substantially slower speeds than at night. So I'm thinking AT&T in my city is either over trafficked now versus six months ago and/or I am being throttled (though I am using the non-NAT elite isp.cingular WAP). So that suggests to me that for the purposes of providing any useful data regarding whether some kind of compression makes any difference for all of us, my wings are clipped.
But I'm still curious. Anybody know a thing or two about this?
If not, but you all share my curiosity and want to get to the bottom of this, I would be happy to set up a series of 10MB (or much larger) files on my mirror, some super compressed, some not at all, whatever, for you to experiment with as these short "speedtest" sites may burst just the right amount and type of data through for your carrier to give you deceptive results. Also with files that size on a fast mirror you can more accurately guage, if you have the right software, comparative battery drain and if there is a difference, does it add up, byte for mAh, to be the same deal either way.
Doug
Was downloading some stuff and noticed slow downloads, so I took a capture, and I see the handset sending lots of TCP ZeroWindow messages.
My understanding is the the handset buffers are getting full and there it's sending kind of a 'pause' message to the server.
assuming that's correct (and please do comment on that), would setting a larger buffer on the handset help?
And if you think it will, how do I go about that?
The device in question is Samsung R720 running 2.3.4, but if there's a general (not device-specific) answer that would be even better.
Thanks,
I have compiled Ezekeel's deepidle into my JellyBean kernel (stock merged to 3.0.39 + voodoo + blx) and got it to run. The kernel seems stable, and I get top-on and top-off stats when I enable WI-FI, but when I disable WI-FI, the stats stop counting.
[EDIT2] I worked out what I think is a bug - see the next post. I am testing my fix now...[/EDIT]
[EDIT] I coded debugging within the DI code and found the offensive DI check. The reason DI does not activate is because the S3C_HSMMC_CLOCK_CARD_EN bit is set for S3C_DEV_HSMMC1 when wi-fi is deactivated. In fact the 'reg2' within cpuidle.c is 0x000f ( it is normally 0xe0003 when wifi is on). To be consistent with Ezekeel's approach I am investigating the S3C_HSMMC_PWRCON registers to see if they can be used. Alternatively if other devices never have 0x000f for reg2, I will use that for a quick 'hack'.
1. Any idea why the S3C_DEV_HSMMC1 register is different for JellyBean vs ICS and GB?
2. How, using the MSMMC registers, can I determine that a device (wi-fi in this case) has been shut down?
[/EDIT]
[ I eagerly await thalamus' IDLE2, but when I compiled it (v 0.213) into my kernel there was an idle battery drain issue. (The screen-off drain was many times my norm, even without music playing...) ]
--== HurryNwait ==--
I think I found the problem, but I feel rather arrogant making the following statement. I think there was a bug in DI all along... (I hope I'm right - maybe someone can check my findings.)
Relevant code:
Code:
#define S3C_HSMMC_CLKCON (0x2c)
...
#define S3C_HSMMC_CLOCK_CARD_EN 0x0004
...
unsigned int reg1, reg2;
...
reg2 = readl(base_addr + S3C_HSMMC_CLKCON);
return !!(reg1 & (S3C_HSMMC_CMD_INHIBIT | S3C_HSMMC_DATA_INHIBIT)) ||
(reg2 & S3C_HSMMC_CLOCK_CARD_EN);
Register offsets and values:
#define S3C_HSMMC_CLKCON (0x2c)
#define S3C_HSMMC_DIVIDER_SHIFT 8
#define S3C_HSMMC_CLOCK_EXT_STABLE 0x0008
#define S3C_HSMMC_CLOCK_CARD_EN 0x0004
#define S3C_HSMMC_CLOCK_INT_STABLE 0x0002
#define S3C_HSMMC_CLOCK_INT_EN 0x0001
Since an unsigned int is 4 bytes, then the "reg2 = read1" line is reading the two bytes we want, and two bytes from the next offset (the last two bytes).
When we do the bitwise comparison - specifically "(reg2 & S3C_HSMMC_CLOCK_CARD_EN)" we are looking at the last two bytes rather than the first two because S3C_HSMMC_CLOCK_CARD_EN is 0x0004 which is compared as 0x00000004.
Also, as it turns out first two bytes are generally 0x000e, so the bitwise test for S3C_HSMMC_CLOCK_CARD_EN always fails if the device is on. Although I could have disabled this test (since it had a bug from the beginning), I am guessing that this test is important, so I changed it to test the S3C_HSMMC_CLOCK_INT_EN bits. I will test it both ways...
I changed the code and now DI works on Jellybean with WI-FI turned off. I am stress testing now and will post my results...
[EDIT] Tested music over bluetooth for 3 hours - no problems - idle stats never stop. Testing music through headphones now... [/EDIT]
(I would be posting in the development section, but I don't have enough posts...)
--== HurryNwait ==--
Well deepidle stats are counting, but I'm back to an old familiar problem. Deep idle is not always stable. I got a reboot while playing music through headphones...
I am currently running ondemand 100 - 1000. I will try something faster...
I am in the process of testing the second iteration of my deepidle fix, and I will ultimately post my patch for the WI-FI off DI bug when I decide if one way is better than the other...
--== HurryNwait ==--
What to do with a mere 100 kilobyte (yes 100KB, 0.1 MB) mobile (GPRS, 3G) data
allowance a day?
I know, I will check the subjects of my mail on my server (not gmail).
Then if I see anything important I will go to where WIFI is for
unlimited browsing.
OK, here's my plan, I will install one of those apps that sends an HTTP
request and prints the result. I will also install a firewall app on my
rooted VITA DOUBLE II MTK6577 Android 4.0.4 phone, to not let any other
apps use my GPRS/3G nor connect to any other site than my mail server.
I will send a http request to a CGI script deep in my site that will
just execute perl's system("mail -H") which will just print a mail
subject and sender summary.
So there, one HTTP request, one response. That ought to do the job
within a mere 1 or 2 kilobytes! If all succeeds then I can start
thinking about what to do with the rest of my data allowance...
Or what if I just connected the default stock email app I see sitting on
my phone and looked at the headers. Perhaps that would do it within 10 KB?
is this a joke?
you had only 100kb for a day and you use it to post a question in a non-QnA forum? :laugh::laugh::laugh:
That was awesome. Lol
Throw away your sim card, get new provider
secret agent needs to communicate on less than 100 KB per day
OK, let's say instead I am an agent about to go to an certain conflict region
where I can still connect to cell towers across the border but I need to
keep communications in the tens of kilobytes per day range in order not
to set off alarms.
As I have root on my android I perhaps could simply write a shell script
that I can run from the (e.g., juicessh local) console, that would
* set up iptables to filter everything except wget
* turn on 2g/3g radio
* run wget example.com/secret_orders.html?agent=007&password=nurd1
* turn off 2g/3g radio
* tear down iptables
I suppose if I instead did
* run ssh [email protected] mail -H
that would rack up 10 times as many bytes.