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

[Binky]

 That makes the chip a faulty product, and by refusing to help me, they are breaking the law.

I wouldn't say it makes the chip faulty, but I would say they could be infringing advertising standards laws.

If the hypothetical chip was marketed as a device that could be used for decoding MP3 files, and then sold without documentation necessary to make it function, then it was missold. That is separate from whether or not it worked as intended by the manufacturer.

Having said that, TI sold the Pandora team a chip that could connect to wlan networks and provided enough software and documentation to build a device that does just that.

The fact that it could be made to function better with the release of additional information is unlikely to have legal weight.

 

[notaz]

The problem most likely is the per-chip-calibration (@notaz) and to some degree maybe within the driver (how it considers calibration).

The driver doesn't care about calibration, it passes it through to the chip without looking at it. The data is likely parsed by ARM9 CPU that sits inside the chip, and we'll never know what's going on after that.

Last but not least: I still hope for input from the hardware engineers / firmware devs on this, as the problem is quite probably already identified somewhere between driver and per-chip-calibration.

Not going to happen, the chip is out of production for quite a while now and the people who designed it already switched multiple projects or even jobs, so even if you succeeded to get their names from TI (which would be very difficult all by itself), it's highly unlikely they'd be able to tell you anything. That chip was developed in like 2006 or 2007..

Now, I might be talking completely rubbish here, since I do not know anything at all about this, really, but my thought would be that with Notaz special kernel module, that can dump calibration data to the file system and read it back again, there might be a possibility to invent some sort of self-calibration tool? As in, something that


* reads the dumped-out data


* does some measurements


* writes back a new version of the calibration data with some adjustments


* restarts the module/reloads calibration data


...and then loops.


Now, this would hinge on firstly, having a good understanding of the calibration data format and what part of the data controls what; secondly, a possibility to do meaningful measurements in some way on the pandora itself; thirdly, to be able to map perceived problems in the measurements to the correct calibration data. That is not at all trivial, I guess. But, still - An idea.

I doubt that would work in automated fashion, unless some sort of metric can be found. The chip as it is now is highly unstable, if you reload the driver like 5 times without making any changes you'll get different behavior each time, and if you actually start making changes you won't be able to tell if those changes actually have effect or it's just acting randomly like it always is. This is what I learned trying to influence it's behavior by doing driver changes, the same happened to MWeston (more or less) while trying hardware changes too.


That said, if someone wants to play around with this mystery calibration data in a hex editor I can provide a dumper and special version of the driver that loads calibration from a file instead of internal EEPROM.

 

[Silent-Hunter]

 That makes the chip a faulty product, and by refusing to help me, they are breaking the law.

I wouldn't say it makes the chip faulty, but I would say they could be infringing advertising standards laws.

If the hypothetical chip was marketed as a device that could be used for decoding MP3 files, and then sold without documentation necessary to make it function, then it was missold. That is separate from whether or not it worked as intended by the manufacturer.

Having said that, TI sold the Pandora team a chip that could connect to wlan networks and provided enough software and documentation to build a device that does just that.

The fact that it could be made to function better with the release of additional information is unlikely to have legal weight.

That depends. Would you say it's working properly? If not, then that would have legal weight. Not to mention that this WiFi problem might be adversely affecting OP's sales, which adds a new problem.

 

[WizardStan]

That depends. Would you say it's working properly? 

Does it connect to wi-fi access points? Can it transfer data? Yes, all advertised features work.Could they work better? Absolutely, but that doesn't matter: so long as it is doing a minimum of what it is advertised to do (which isn't much) then everything is "working". There's no legal recourse here.

 

[EvilDragon]

@EvilDragon & @Askarus: As I told you privately via email, I had wanted my Pandora tested particularly scrutenely, before sending the third Pandora to me. WiFi was found to be working at OpenPandora Gmbh. When I got it, it obviously didn't (in various environments under high scrutiny). Therefore I doubted your testing method/environment. I cannot stress it enough: Please test with a default dumb consumer router, not one very particular one, which just luckily works fine with the "cranky and idiosyncratic" (@vandyswa) Pandora WiFi chip.

We used two different standard consumer routers.


One is the one we always use for testing (forgot the brand right now), the other one a standard FritzBox, probably the mostly used consumer router brand in Germany (as every internet provider gives you one for free).


Stable 600kb/s (same my N900 does on these routers) on both of these routers was good enough, don't you think?


You are very welcome sending us as many routers as you like for testing, but I certainly won't buy 10 different routers just to test your Pandora, unless you'd like to buy additional 10 Pandoras (otherwise, where should the profit for the routers come from?)

 

[Silent-Hunter]

That depends. Would you say it's working properly? 

Does it connect to wi-fi access points? Can it transfer data? Yes, all advertised features work.
Could they work better? Absolutely, but that doesn't matter: so long as it is doing a minimum of what it is advertised to do (which isn't much) then everything is "working". There's no legal recourse here.

Not for everyone though. If there's that many that don't work, and TI could do something about it, shouldn't they have to? I just think it's stupid, and they have no reason not to give out the info.

 

[Askarus]

@EvilDragon & @Askarus: As I told you privately via email, I had wanted my Pandora tested particularly scrutenely, before sending the third Pandora to me. WiFi was found to be working at OpenPandora Gmbh. When I got it, it obviously didn't (in various environments under high scrutiny). Therefore I doubted your testing method/environment. I cannot stress it enough: Please test with a default dumb consumer router, not one very particular one, which just luckily works fine with the "cranky and idiosyncratic" (@vandyswa) Pandora WiFi chip.

We used two different standard consumer routers.


One is the one we always use for testing (forgot the brand right now), the other one a standard FritzBox, probably the mostly used consumer router brand in Germany (as every internet provider gives you one for free).


Stable 600kb/s (same my N900 does on these routers) on both of these routers was good enough, don't you think?


You are very welcome sending us as many routers as you like for testing, but I certainly won't buy 10 different routers just to test your Pandora, unless you'd like to buy additional 10 Pandoras (otherwise, where should the profit for the routers come from?)

Right.

I did the tests with sysinfo.

I also was browsing the web with you latest Pandora. It was fine.

I was downloading some big data as well (battle for wesnoth I think).

So for me it was working.

It was the same Router I use with my Pandora to go online in the Dragon Box shop.

This facts support the "it's router specific" theory.

 

[Neelix]

No manufacturer is going to guarantee that their product plays well with every combination of hardware and software out there. That's just not practical. Their are so many variations not to mention environmental factors that it's almost certain there are always going to be situations where a given product doesn't work. That just means it's not the right product for the job. Then it's up to the end user to find the product that is.

- Neelix

 

[steveway]

The problem most likely is the per-chip-calibration (@notaz) and to some degree maybe within the driver (how it considers calibration).

The driver doesn't care about calibration, it passes it through to the chip without looking at it. The data is likely parsed by ARM9 CPU that sits inside the chip, and we'll never know what's going on after that.

>Last but not least: I still hope for input from the hardware engineers / firmware devs on this, as the problem is quite probably already identified somewhere between driver and per-chip-calibration.

Not going to happen, the chip is out of production for quite a while now and the people who designed it already switched multiple projects or even jobs, so even if you succeeded to get their names from TI (which would be very difficult all by itself), it's highly unlikely they'd be able to tell you anything. That chip was developed in like 2006 or 2007..

Now, I might be talking completely rubbish here, since I do not know anything at all about this, really, but my thought would be that with Notaz special kernel module, that can dump calibration data to the file system and read it back again, there might be a possibility to invent some sort of self-calibration tool? As in, something that


* reads the dumped-out data


* does some measurements


* writes back a new version of the calibration data with some adjustments


* restarts the module/reloads calibration data


...and then loops.


Now, this would hinge on firstly, having a good understanding of the calibration data format and what part of the data controls what; secondly, a possibility to do meaningful measurements in some way on the pandora itself; thirdly, to be able to map perceived problems in the measurements to the correct calibration data. That is not at all trivial, I guess. But, still - An idea.

I doubt that would work in automated fashion, unless some sort of metric can be found. The chip as it is now is highly unstable, if you reload the driver like 5 times without making any changes you'll get different behavior each time, and if you actually start making changes you won't be able to tell if those changes actually have effect or it's just acting randomly like it always is. This is what I learned trying to influence it's behavior by doing driver changes, the same happened to MWeston (more or less) while trying hardware changes too.


That said, if someone wants to play around with this mystery calibration data in a hex editor I can provide a dumper and special version of the driver that loads calibration from a file instead of internal EEPROM.

I've got access to some software that does some graphical analyzing on binary data at work. I would take a look and see if there is anything jumps my eye if you provide me a copy of the EEPROM data or the dumper so I can get it from my pandora. Would be interesting to take a look.

 

[WizardStan]

Not for everyone though.

Name one person who has never been able to get a connection at all. We've got users with slow connections and users who can't hold a connection, but it is still connecting.Also, the fact that this chip was in use long before the Pandora got it with no complaints suggests that other companies were able to figure it out. All the information to make it work is probably there, we just don't have the same size of dedicated team to make it work. Nokia had an entire engineering team, I wouldn't be surprised if they had one person who's job it was to study the available documents and make sure they did everything that was needed.

 

[moxie]

Now, I might be talking completely rubbish here, since I do not know anything at all about this, really, but my thought would be that with Notaz special kernel module, that can dump calibration data to the file system and read it back again, there might be a possibility to invent some sort of self-calibration tool?

[...] thirdly, to be able to map perceived problems in the measurements to the correct calibration data. That is not at all trivial, I guess. But, still - An idea.

I doubt that would work in automated fashion, unless some sort of metric can be found. The chip as it is now is highly unstable, if you reload the driver like 5 times without making any changes you'll get different behavior each time, and if you actually start making changes you won't be able to tell if those changes actually have effect or it's just acting randomly like it always is.

No, I understand that (that's what I meant by the third point above). OTOH, if it is that unstable, it makes it even less of a possibility. Darn.

 

[porg]

The driver doesn't care about calibration, it passes it through to the chip without looking at it. The data is likely parsed by ARM9 CPU that sits inside the chip, and we'll never know what's going on after that.

[…] the chip is out of production for quite a while now and the people who designed it already switched multiple projects or even jobs, so even if you succeeded to get their names from TI (which would be very difficult all by itself), it's highly unlikely they'd be able to tell you anything. That chip was developed in like 2006 or 2007..

[…] invent some sort of self-calibration tool?

I doubt that would work in automated fashion, unless some sort of metric can be found. The chip as it is now is highly unstable, if you reload the driver like 5 times without making any changes you'll get different behavior each time, and if you actually start making changes you won't be able to tell if those changes actually have effect or it's just acting randomly like it always is. This is what I learned trying to influence it's behavior by doing driver changes, the same happened to MWeston (more or less) while trying hardware changes too.


That said, if someone wants to play around with this mystery calibration data in a hex editor I can provide a dumper and special version of the driver that loads calibration from a file instead of internal EEPROM.

Ok, so I have @notaz, one of the senior Pandora developers, confirming again that the chip is very unstable ("cranky and idiosyncratic" as @vandyswa put it) and unlikely to get solved, for the reasons of a company (TI) not really willing to cooperate (for economical reasons, legally protected).

 

@EvilDragon & @Askarus: As I told you privately via email, I had wanted my Pandora tested particularly scrutenely, before sending the third Pandora to me. WiFi was found to be working at OpenPandora Gmbh. When I got it, it obviously didn't (in various environments under high scrutiny). Therefore I doubted your testing method/environment. I cannot stress it enough: Please test with a default dumb consumer router, not one very particular one, which just luckily works fine with the "cranky and idiosyncratic" (@vandyswa) Pandora WiFi chip.

We used two different standard consumer routers.
One is the one we always use for testing (forgot the brand right now), the other one a standard FritzBox, probably the mostly used consumer router brand in Germany (as every internet provider gives you one for free).


Stable 600kb/s (same my N900 does on these routers) on both of these routers was good enough, don't you think?


You are very welcome sending us as many routers as you like for testing, but I certainly won't buy 10 different routers just to test your Pandora, unless you'd like to buy additional 10 Pandoras (otherwise, where should the profit for the routers come from?)

And, @EvilDragon, the senior Pandora entrepreneur, which tells, that testing cannot be improved, unless further testing devices would be donated.

(Ideology: We are not customers, with a right to get products as advertised, but community members, which somehow MUST participate/help in the community, to get what was advertised. To some degree this is ok, as I wanted to participate in the adventure of one of the first crowd funded electronic devices, long before KickStarter. I still think it was awesome, what this was achieved, only the suffering turned out to be a bit too much for me eventually.)

Grim perspective. But I still don't give up yet! I like the community/nerd adventure part:

1) A friend owns a FritzBox router, and I will test my Pandora over there.

2) a ) @steveway offered to analyse binary calibration profiles.

b ) @notaz: Could you please provide the tool to extract the calibration data? I would like to do this, and provide my WiFi calibration profile here, maybe others are willing to provide their calibration dumps as well, and then @steveway can have a look at them all. Maybe he finds the needle in the haystack.

 

[mindlord]

I will submit calibration data if I can have access to the tool

 

[Silent-Hunter]

Not for everyone though.

Name one person who has never been able to get a connection at all. We've got users with slow connections and users who can't hold a connection, but it is still connecting.
Also, the fact that this chip was in use long before the Pandora got it with no complaints suggests that other companies were able to figure it out. All the information to make it work is probably there, we just don't have the same size of dedicated team to make it work. Nokia had an entire engineering team, I wouldn't be surprised if they had one person who's job it was to study the available documents and make sure they did everything that was needed.

I suppose. My gut just says something stinks. Did Nokia get the same level of support as OPT? I'm just wondering if this is one of those cases of a big company giving preferential treatment to other big companies over the smaller ones.

Also, I thought there were some people that couldn't connect at all? Maybe I misread something?

 

[zapman]

My observations on wifi performance:


On the same router, performance is a lot lot better if you dont have any wifi encryption enabled.


In areas where there are very few additinal wifis around, performance is much better then in areas with lots of wifis (few wifis: 1-2. Lots of wifis: 20-30). Signal strenght is comparable in both situations. Other wifi gadgets dont have any problems with crowded wifi areas.


To me it seems that this influences performance more than router brand or wifi channel.

 

[thatgui]

Seems I was quite lucky with the two devices I had over the years (one CC, one Rebirth) both worked in at least 9 or 10 different environments quite well - altough I never got maximum speed (average 270 kB/s), datarates never got below 100 kb/s. I even updated the CodeBlocks Package through PNDManager two times already. There were several AVM Accesspoints (mostly Fritboxes of different versions), D-Link, crappy ones from Philips, most of them in "heavy airwave traffic" environments.

 

[notaz]

I suppose. My gut just says something stinks. Did Nokia get the same level of support as OPT? I'm just wondering if this is one of those cases of a big company giving preferential treatment to other big companies over the smaller ones.

Well it was always a problem to get help from TI, I remember MWeston used to have to wait months for answers on simple board design questions.. The situation has improved a bit when they set up that e2e "community" site with dedicated support people answering threads there, but still it was like 50% chance your question will be answered, and by the time it was set up you already get "your chip is old and unsupported" type of answers.

About Nokia, they also had their reasons to rewrite the TI driver from scratch.

 

[porg]

@notaz, we are waiting for a response concerning your calibration dump tool. Thanks!

 

[porg]

Today I tested my Pandora with my router D-Link DI-524 without encryption (my original report tested with WPA-PSK on various channels). Same disappointing result.

I am doubting whether encryption plays a role in this issue. On what layer does WiFi encryption take place?

Deep enough (on the chip) so that it can be troubled by powersaving, or higher up (in the driver or OS), where it would be unrelated to the lower powersaving/connection issues?

 

[notaz]

@notaz, we are waiting for a response concerning your calibration dump tool. Thanks!

That's not easily done, if my day job was maintaining pandora firmware I could provide it in timely fashion, now I don't know how many tired-after-work evenings that would take and it's not my top priority.