Jump to content


Photo

Wifi

- - - - -

  • Please log in to reply
15 replies to this topic

#1
t0mm13b

t0mm13b

    Hardcore

  • MoDaCo Silver
  • PipPipPipPipPipPip
  • 1,784 posts
  • Gender:Male
  • Location:Ireland
  • Devices:GT-S8500,Zte Blade,SE ST15i
  • Twitter:@t0mm13b
Have been looking at the modaco rom alpha 5, in conjunction with kernel 2.6.32, there seems to be a huge juice drain with wifi switched on, and am wondering is there more than one wifi kernel driver being loaded?
  • ar6000.ko
  • athtcmd_ram.bin
  • athwlan.bin.z77
  • data.patch.hw2_0.bin
By perchance, a wrong driver could significantly drain the juice yes?

Those are found in the system/wifi directory...

What is the actual chipset used for the wifi... :D

Edited by t0mm13b, 12 January 2011 - 03:30 PM.

  • 0
try{ not_laugh; }catch{ FAIL; }finally{ laugh; }

#2
fonix232

fonix232

    Addict

  • Members
  • PipPipPipPipPip
  • 942 posts
  • Location:Hungary, Debrecen
  • Devices:ZTE Blade [TFT 512RAM]
  • Twitter:@fonix232

Have been looking at the modaco rom alpha 5, in conjunction with kernel 2.6.32, there seems to be a huge juice drain with wifi switched on, and am wondering is there more than one wifi kernel driver being loaded?

  • ar6000.ko
  • athtcmd_ram.bin
  • athwlan.bin.z77
  • data.patch.hw2_0.bin
By perchance, a wrong driver could significantly drain the juice yes?

Those are found in the system/wifi directory...

What is the actual chipset used for the wifi... :D


The chipset is the Atheros AR6000. ar6000.ko is the specified driver loader for the AR6000, the ath*.bin(.z77) files are the drivers itselves, and the data.patch file is something what I guess is a patch for the hardware drivers.
Wifi drains are caused by a, too frequent scans (kallt's ROMs have a lower set of scan frequency), or b, too much power usage (I remember seeing an app what could set the voltage of the WiFi antennae somewhere, can't recall where or when sadly :S). It is definitely not the driver!

  • 0
If you like my work, invite me for a drink or two!

Also, take a look at my Blade-dedicated site too! fonix232.co.cc

#3
t0mm13b

t0mm13b

    Hardcore

  • MoDaCo Silver
  • PipPipPipPipPipPip
  • 1,784 posts
  • Gender:Male
  • Location:Ireland
  • Devices:GT-S8500,Zte Blade,SE ST15i
  • Twitter:@t0mm13b

The chipset is the Atheros AR6000. ar6000.ko is the specified driver loader for the AR6000, the ath*.bin(.z77) files are the drivers itselves, and the data.patch file is something what I guess is a patch for the hardware drivers.
Wifi drains are caused by a, too frequent scans (kallt's ROMs have a lower set of scan frequency), or b, too much power usage (I remember seeing an app what could set the voltage of the WiFi antennae somewhere, can't recall where or when sadly :S). It is definitely not the driver!


Darn, I wish I could upvote your answer .... +1 from me...

too many frequent scans... hmmm... must dig that around... I knew they were firmware binaries specifically.... but answer me this

why is it not using the latest kernel version instead of the rom version?

Thanks for your enlightening answer... :D

  • 0
try{ not_laugh; }catch{ FAIL; }finally{ laugh; }

#4
t0mm13b

t0mm13b

    Hardcore

  • MoDaCo Silver
  • PipPipPipPipPipPip
  • 1,784 posts
  • Gender:Male
  • Location:Ireland
  • Devices:GT-S8500,Zte Blade,SE ST15i
  • Twitter:@t0mm13b

Darn, I wish I could upvote your answer .... +1 from me...

too many frequent scans... hmmm... must dig that around... I knew they were firmware binaries specifically.... but answer me this

why is it not using the latest kernel version instead of the rom version?

Thanks for your enlightening answer... :D


HEre's the linky to the latest code base regarding ar6k...

  • 0
try{ not_laugh; }catch{ FAIL; }finally{ laugh; }

#5
jonuwz

jonuwz

    Newbie

  • Members
  • Pip
  • 29 posts

Darn, I wish I could upvote your answer .... +1 from me...

too many frequent scans... hmmm... must dig that around... I knew they were firmware binaries specifically.... but answer me this

why is it not using the latest kernel version instead of the rom version?

Thanks for your enlightening answer... :D


Set the scan interval in /system/build.prop

wifi.supplicant_scan_interval=xx

where xx seems to be 15 seconds by default

  • 0

#6
Scope

Scope

    Newbie

  • Members
  • Pip
  • 29 posts

Set the scan interval in /system/build.prop

wifi.supplicant_scan_interval=xx

where xx seems to be 15 seconds by default


What is the interval used for? When you startup from sleep, or is it actually used when the phone is switched on and wifi in use?

  • 0

#7
jonuwz

jonuwz

    Newbie

  • Members
  • Pip
  • 29 posts

The chipset is the Atheros AR6000. ar6000.ko is the specified driver loader for the AR6000, the ath*.bin(.z77) files are the drivers itselves, and the data.patch file is something what I guess is a patch for the hardware drivers.
Wifi drains are caused by a, too frequent scans (kallt's ROMs have a lower set of scan frequency), or b, too much power usage (I remember seeing an app what could set the voltage of the WiFi antennae somewhere, can't recall where or when sadly :S). It is definitely not the driver!



It could be that the WifiService isn't attempting (or failing) to change the PM profile, or the AR6K chipset only has 'on' and 'off'

poking around in dmesg might reveal some PM messages for wifi.

Doubt its anything we could fix in the non-AOSP implementation of framework anyway.

  • 0

#8
jonuwz

jonuwz

    Newbie

  • Members
  • Pip
  • 29 posts

What is the interval used for? When you startup from sleep, or is it actually used when the phone is switched on and wifi in use?


Whenever wifi is active.
It scans for new access points.

So if your wifi is on, and you get home, within 15 seconds it should discover your AP and connect if it been connected in the past.
Thats if your wifi is on though

  • 0

#9
Scope

Scope

    Newbie

  • Members
  • Pip
  • 29 posts

Whenever wifi is active.
It scans for new access points.

So if your wifi is on, and you get home, within 15 seconds it should discover your AP and connect if it been connected in the past.
Thats if your wifi is on though


Thanks mate. Does it use the interval when you switch the phone on aswell? Or is it clever enough to think that "I have been switched on, so I will go and look for an AP right now, rather than waiting for X seconds".. If thats the case having it set to say 180 seconds, as JJ6 does, isnt really an issue, as long as it doesnt wait 180 seconds from switching the phone off / enabling Wifi.

  • 0

#10
Quu

Quu

    Enthusiast

  • Members
  • PipPipPip
  • 165 posts
  • Devices:ZTE Blade

Thanks mate. Does it use the interval when you switch the phone on aswell? Or is it clever enough to think that "I have been switched on, so I will go and look for an AP right now, rather than waiting for X seconds".. If thats the case having it set to say 180 seconds, as JJ6 does, isnt really an issue, as long as it doesnt wait 180 seconds from switching the phone off / enabling Wifi.

It scans all the time when wifi is on. (every 15th second that is)

  • 0

#11
Scope

Scope

    Newbie

  • Members
  • Pip
  • 29 posts

It scans all the time when wifi is on. (every 15th second that is)


Yes I got that, but when you switch the phone on (from sleep), does it do the first scan straight away (ideally), or does it wait for X seconds, as configured under wifi.supplicant_scan_interval? If it does it straight away I dont see a problem having high number to reduce the battery usage, if however it doesnt start looking until it has reached X seconds I can see issues having it high, as you would have to wait X seconds before it start scanning and connects you.. This ofcourse is only an issue if the number is high (for example 180 as in the JJ6 rom)

  • 0

#12
fonix232

fonix232

    Addict

  • Members
  • PipPipPipPipPip
  • 942 posts
  • Location:Hungary, Debrecen
  • Devices:ZTE Blade [TFT 512RAM]
  • Twitter:@fonix232

Yes I got that, but when you switch the phone on (from sleep), does it do the first scan straight away (ideally), or does it wait for X seconds, as configured under wifi.supplicant_scan_interval? If it does it straight away I dont see a problem having high number to reduce the battery usage, if however it doesnt start looking until it has reached X seconds I can see issues having it high, as you would have to wait X seconds before it start scanning and connects you.. This ofcourse is only an issue if the number is high (for example 180 as in the JJ6 rom)


AFAIK, by the standard ZTE Radio, the WiFi is switched off whenever the phone is turned into sleep mode.
When you reactivate your phone (power button wake), first wifi scan is done. That causes the well known wifi bug.

The Hungarian update fixes it in a weird way, as it won't let the wifi sleep when there is an active connection, but somewhy the framework disconnects and tries to reconnect when the phone is waken up.

  • 0
If you like my work, invite me for a drink or two!

Also, take a look at my Blade-dedicated site too! fonix232.co.cc

#13
oh!dougal

oh!dougal

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 1,022 posts
  • Location:England
  • Devices:DX2 FroYo San Francisco

...
The Hungarian update fixes it in a weird way, as it won't let the wifi sleep when there is an active connection, but somewhy the framework disconnects and tries to reconnect when the phone is waken up.

Disconnects? Doesn't the wifi power simply get cut off by the power management?

  • 0

#14
fonix232

fonix232

    Addict

  • Members
  • PipPipPipPipPip
  • 942 posts
  • Location:Hungary, Debrecen
  • Devices:ZTE Blade [TFT 512RAM]
  • Twitter:@fonix232

Disconnects? Doesn't the wifi power simply get cut off by the power management?


IF there is an active connection (MSN, torrent or download, youtube video, GTalk, syncing, etc) then it won't get cut off. That's why the framework bug appears (sadly) so it disconnects :S

  • 0
If you like my work, invite me for a drink or two!

Also, take a look at my Blade-dedicated site too! fonix232.co.cc

#15
t0mm13b

t0mm13b

    Hardcore

  • MoDaCo Silver
  • PipPipPipPipPipPip
  • 1,784 posts
  • Gender:Male
  • Location:Ireland
  • Devices:GT-S8500,Zte Blade,SE ST15i
  • Twitter:@t0mm13b

HEre's the linky to the latest code base regarding ar6k...


Can anyone smarter than me, tell me is this driver backwards compatible with ar6k driver as found in the openmoko source. Here's the linky to ath6kl....? :D

Much appreciated... :P

  • 0
try{ not_laugh; }catch{ FAIL; }finally{ laugh; }

#16
t0mm13b

t0mm13b

    Hardcore

  • MoDaCo Silver
  • PipPipPipPipPipPip
  • 1,784 posts
  • Gender:Male
  • Location:Ireland
  • Devices:GT-S8500,Zte Blade,SE ST15i
  • Twitter:@t0mm13b

Can anyone smarter than me, tell me is this driver backwards compatible with ar6k driver as found in the openmoko source. Here's the linky to ath6kl....? B)

Much appreciated... :P


Wait up...

Can I have your attention? Is it me or there's a probability that the driver that is loaded on the modaco rom is incorrect - hence battery juice drains faster????? :D

like I am not 100% sure but could loading a wrong wifi driver (Despite being compatible) could have implications for battery juice being sucked up too quickly on the modaco rom alpha r5?

Just saw this linky on another thread regarding USB OTG and its hosted on a chinese website about Qualcomm's MSM7227.... On page 2 on that site, its Atheros AR6002... :P

FYI Paul - can this be confirmed or verified? OR am I barking up the wrong tree? :P

Edited by t0mm13b, 13 January 2011 - 07:31 PM.

  • 0
try{ not_laugh; }catch{ FAIL; }finally{ laugh; }




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users