15 replies to this topic

[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...

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

[fonix232]

t0mm13b, on Jan 12 2011, 18:28, said:

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...

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!

[t0mm13b]

fonix232, on Jan 12 2011, 16:00, said:

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...

[t0mm13b]

t0mm13b, on Jan 12 2011, 16:09, said:

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...

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

[jonuwz]

t0mm13b, on Jan 12 2011, 17:09, said:

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...

Set the scan interval in /system/build.prop

wifi.supplicant_scan_interval=xx

where xx seems to be 15 seconds by default

[Scope]

jonuwz, on Jan 12 2011, 16:19, said:

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?

[jonuwz]

fonix232, on Jan 12 2011, 17:00, said:

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.

[jonuwz]

Scope, on Jan 12 2011, 17:24, said:

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

[Scope]

jonuwz, on Jan 12 2011, 16:34, said:

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.

[Quu]

Scope, on Jan 12 2011, 18:44, said:

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)

[Scope]

Quu, on Jan 12 2011, 16:54, said:

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)

[fonix232]

Scope, on Jan 12 2011, 20:00, said:

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.

[oh!dougal]

fonix232, on Jan 12 2011, 17:07, said:

...
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?

[fonix232]

oh!dougal, on Jan 12 2011, 20:32, said:

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

[t0mm13b]

t0mm13b, on Jan 12 2011, 16:14, said:

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....?  

Much appreciated...

[t0mm13b]

t0mm13b, on Jan 12 2011, 19:29, said:

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....?  

Much appreciated...

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?????  

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...  

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

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