WiFi mysteries resolved once and for all — Power saving is clearly the culprit!

[b_o_b]

With a bit of terminal skills it seems to be not too hard to do, but I like the idea of a script, I am willing to try it on 2 classic pandora's.  

 

[_wb_]

Why not make a small PND that just does the dump to a file, then does some standard wifi speed test, and uploads the dump (maybe with the mac address removed for privacy reasons) and speed benchmark results to some public ftp server (or gives you a file that you can upload yourself if your Pandora wifi is too crappy) where anyone can download the data to investigate what could cause the trouble?

 

[ibisum]

Or it could just be sent out to a web-server somewhere for collection, also do'able.

But I think having the calibration data in PSI would be a great move, though, regardless!

 

[EvilDragon]

Um, wait, as far as I know, the dump will be the same on every unit (except for the mac address).


This is the actual calibration data that's used on every unit (a fixed one).


The modified driver also allows to upload different calibration data onto the chip.


However, there's no process yet to CREATE calibration data based on your environment.

 

[_wb_]

There do seem to be differences between the dumps though, at least porg's dump differs from any of the 3 other dumps notaz has on http://notaz.gp2x.de/misc/pnd/wl1251/nvs_samples/

 

[ShleeDragon]

Problem solved.

 

[EvilDragon]

There do seem to be differences between the dumps though, at least porg's dump differs from any of the 3 other dumps notaz has on http://notaz.gp2x.de/misc/pnd/wl1251/nvs_samples/

Hmm, okay that's weird... but if the driver had the possibility to calibrate itself, it should work properly, right?


Or maybe... as mentioned, those chips are all calibrated when they are being produced, so they can be different but I don't think they help a lot with debugging here.


What we'd need is a tool that somehow creates automatic calibration data in each unit. That calibration data would need to be measured somehow.


Ideally, we would include that in the testing/flashing script for GC so that all units will be calibrated when they are assembled before they're being shipped.

 

[notaz]

Or maybe... as mentioned, those chips are all calibrated when they are being produced, so they can be different but I don't think they help a lot with debugging here.

Yes they are, every chip has different calibration inside of EEPROM (created and flashed by manufacturer, it's what the hacked driver dumps), this is long known. It's possible this calibration is wrong for populated chips, and maybe some values from good working pandoras could be copied to bad ones and would help.

What we'd need is a tool that somehow creates automatic calibration data in each unit. That calibration data would need to be measured somehow.


Ideally, we would include that in the testing/flashing script for GC so that all units will be calibrated when they are assembled before they're being shipped.

Sure that would be best, but I don't think it's realistic to make such tool ourselves, even to derive it from TI wl1271 one (it's for totally different calibration type and driver).

 

[Galaxis]

Yes they are, every chip has different calibration inside of EEPROM (created and flashed by manufacturer, it's what the hacked driver dumps), this is long known. It's possible this calibration is wrong for populated chips, and maybe some values from good working pandoras could be copied to bad ones and would work.

Could be worth a try collecting a few samples from "good" Pandoras - at least to compare if they have something in common.

Is it possible that the soldering process tips over a couple of random bits in EEPROM (chip getting too warm maybe)?

 

[notaz]

Is it possible that the soldering process tips over a couple of random bits in EEPROM (chip getting too warm maybe)?

That's highly unlikely, >90% of file is consistent between all dumps I've seen, if there was corruption it would be random all over the place.

 

[Neelix]

Well I consider my wifi to be acceptable on my unit, so here's mine.  Hope it helps.

Note: I have redacted the MAC address in a hex editor before posting (I replaced it with 00:00:00:00:00:00)

- Neelix

EDIT:   For the record my unit is a Rebirth edition,  and I connect though an ASUS WL520gc router. (802.11g)

 

[EvilDragon]

Okay, good to know.

I'll take a couple of units home, test them under the same environment, post the network transfer rates as well as the NVS dump then.

Maybe we can use the diffs to improve the WiFi in every area.

 

[Neelix]

wl12xx is completely different driver for wl1271 and newer chips, our chip is wl1251 and uses wl1251 driver that this tool won't support.

Maybe it can be hacked to work somehow, who knows, but I feel tired even thinking about attempting it (I've burned up trying these things years ago..)

If I understand it correctly this page seems to suggest  that it can:

http://forum.xda-developers.com/wiki/HTC_Raphael/WL1251

Though the instructions seem to contain some vendor specific debugfs paths which I figure would need to be translated in order to make it work...  

Also the wiki says that loading NVS from a file will result in a random MAC address.   Does this mean the driver actually chooses a random address in this case, or is it just effectively random because you're most likely loading someone elses NVS with their MAC?

- Neelix

 

[EvilDragon]

wl12xx is completely different driver for wl1271 and newer chips, our chip is wl1251 and uses wl1251 driver that this tool won't support

Maybe it can be hacked to work somehow, who knows, but I feel tired even thinking about attempting it (I've burned up trying these things years ago..)

If I understand it correctly this page seems to suggest  that it can:
http://forum.xda-developers.com/wiki/HTC_Raphael/WL1251

Though the instructions seem to contain some vendor specific debugfs paths which I figure would need to be translated in order to make it work...

As far as I understand it, their driver needs an NVS file which they dump off the chip as well, it doesn't create one itself.

 

[notaz]

Neelix probably wanted to say that they are using wl12xx driver on wl1251, but this is not the case. Long ago wl1251 and wl12xx drivers used to live in the same directory called wl12xx in kernel, but they were always separate - instructions in that wiki page already tell you to load  wl1251_sdio, not wl12xx_sdio (which is a driver for wl1271+ chips).

That page reminded me of another thing though - multiple firmware files (wl1251-fw.bin or Fw1251r1c.bin) exist and they work different. I remember ED tested all of them and found the one we currently use to work best, but other devices use other files, so this is something to test again.

 

[Neelix]

@Notaz: That is indeed what I was getting at.   Thanks for the clarification.

- Neelix

 

[EvilDragon]

Should we create a PND that uploads different firmwares and NVS files, connects to our server and downloads a 5MB file each time and creates a table file (CSV?) which shows the statistics (download speed, NVS file used, firmware used)?

 

[Zero3K]

Should we create a PND that uploads different firmwares and NVS files, connects to our server and downloads a 5MB file each time and creates a table file (CSV?) which shows the statistics (download speed, NVS file used, firmware used)?

That would be nice.

 

[notaz]

Should we create a PND that uploads different firmwares and NVS files, connects to our server and downloads a 5MB file each time and creates a table file (CSV?) which shows the statistics (download speed, NVS file used, firmware used)?

I don't know if that's worth the effort. Maybe porg could load Neelix's NVS and check for improvements?

BTW did some PHP coding today:

http://notaz.gp2x.de/misc/pnd/wl1251/nvs_sample_compare.php

 

[mcobit]

Can't you just crank up the gain, reupload and see if it improves?