Quality Control


clyborg

Still Fresh
Joined
Jun 8, 2009
Messages
52
With the current WiFi issue, how did this problem slip pass the whole design, build, and testing process?

http://www.open-pandora.org/index.php?option=com_content&view=article&id=98&Itemid=13&lang=en

The completed tasks should have caught the wifi issue:

1. Board Design (I'm assuming the wifi chip was chosen, and the driver was available at that time)
2. Burn-In and Stability Tests for the 105 Boards (Testing before or after to burn-in should have had testing for all components.)
3. testing for FCC/CE compliance (How did the FCC test this if WiFi was not working?)

After the FCC/CE compliance task, there is no other task listed to test the Pandora. I really do not want a rushed product, but some of these delays could have been caught prior to the cases being built. If testing is lacking, what else was over-looked?

I'm trying not to beat a dead horse or slam the team in anyway, but I'm just a concerned consumer.


Jason
 
Clyborg said:
The completed tasks should have caught the wifi issue:
1. Board Design (I'm assuming the wifi chip was chosen, and the driver was available at that time)

If you followed the blog, you knew there were problems with getting the driver to work correctly.
It does run, but it has a max peak of 45KB/s. The module itself does work though.

2. Burn-In and Stability Tests for the 105 Boards (Testing before or after to burn-in should have had testing for all components.)

Each hardware component is being tested, also the WiFi module. It does start, connect to an AP and can ping a server. That's all we could to for a hardware test.

3. testing for FCC/CE compliance (How did the FCC test this if WiFi was not working?)

As said, the WiFi module does work. It can be switched on and connect to the internet. FCC/CE compliance doesn't care about slow speed.

After the FCC/CE compliance task, there is no other task listed to test the Pandora. I really do not want a rushed product, but some of these delays could have been caught prior to the cases being built. If testing is lacking, what else was over-looked?

WiFi was the only thing where our couldn't get the driver fully working.
We hoped it would work out until now, and things got better. We can get stable speeds without packet loss, but we don't know yet why it's slow.

Every other aspect (nubs, Audio, 3D processor, keyboard, screen, DPad, SD-Card slots, USB-connector, TV Out, charger, etc.) are working fine as we are working with all that already on our units for months.

We still hope it's a software issue, but who could tell it is for sure until you get it to work 100%?

One thing we don't want to do is hide that from you, so we didn't want to silently build the Pandoras and ship them to you, telling it can't possibly be hardware, and then later it might turn out it IS hardware indeed.

I know other companies probably wouldn't have cared about that and simply delivered...
But I do think this project is based on trust. I trust you guys will support us if we openly tell you what's happening.
Even if we find out it's hardware within the next days, I do think being open about it is the right way to go. The way to keep you guys supporting us.

We are no big company with billions of USD nor are we magicians, we cannot snip with our fingers and make WiFi working.
All we can do is offer to assemble and ship the units we have right now and fix it later, so you can finally start using your Pandora and know this last thing will be taken care of.

If it turns out to be wrong - and you'd all immediately abandon the project because we told you of problems instead of silently ship it anyways... it would really hurt me a lot.
For me, this community is the coolest one I've ever seen. It always kept me motivated to work on the Archive, the website, the server in my free time and to open up a shop to make sure you can easily buy such handhelds with the best customer support I can possibly provide.
I never charged anything for let you use the archives nor for hosting this website (and yes, it does cost me money).
It's what I want to give to the community, as the community gave me a lot of cool games and apps for all the open handhelds.

And I still do think that if you help someone, he will also help you when you're in need. So let's go on and play with out Pandoras soon! :D
 
Last edited:
EvilDragon said:
One thing we don't want to do is hide that from you, so we didn't want to silently build the Pandoras and ship them to you, telling it can't possibly be hardware, and then later it might turn out it IS hardware indeed.

Yup, I would frown if that happened. I'm hopeful the wi-fi problem is software, and is fixed once there's a few hundred Panny's in the wild in skilled hands. :)
 
Last edited by a moderator:
EvilDragon said:
We are no big company with billions of USD nor are we magicians, we cannot snip with our fingers and make WiFi working.
All we can do is offer to assemble and ship the units we have right now and fix it later, so you can finally start using your Pandora and know this last thing will be taken care of.

If it turns out to be wrong - and you'd all immediately abandon the project because we told you of problems instead of silently ship it anyways... it would really hurt me a lot.
For me, this community is the coolest one I've ever seen. It always kept me motivated to work on the Archive, the website, the server in my free time and to open up a shop to make sure you can easily buy such handhelds with the best customer support I can possibly provide.
I never charged anything for let you use the archives nor for hosting this website (and yes, it does cost me money).
It's what I want to give to the community, as the community gave me a lot of cool games and apps for all the open handhelds.

And I still do think that if you help someone, he will also help you when you're in need. So let's go on and play with out Pandoras soon! :D

I think this is something everyone needs to keep in mind. This isn't the effort of a major multi-billion dollar corporation - it's an effort driven by some very talented members of the best open source gaming community for handheld devices.

Yes, there have been some problems along the way. But, they're about to release the best open source handheld that this community could have ever hoped for. It's absolutely everything we've ever wanted in a handheld. AND, it was done without the requisite millions of dollars for R&D - it was born from the dreams of this community.

Sure, it's taken a while to get to this point. But, we're almost there! Craig, EvilDragon, MWeston, Faith, and everyone else involved have put in a lot of work, and have taken quite a risk by getting involved with this venture. Everyone needs to respect that, and take that into consideration before getting too critical about delays and development problems.
 
Last edited by a moderator:
@ED : what type of product is this WiFi module ?
Are the specs available ?
Anything related to TI ?
I ask because i was reading recently an article about a driver issue with a Wifi module by TI...IIRC is related to a malfunction with 2.6.29 Linux Kernel...
 
I'd be putting 2.6.34 on the PandoraOS ASAP, guys. Definitely worth the effort, just look at the changelog for the wlxxx driver tree already ..
 
torpor said:
I'd be putting 2.6.34 on the PandoraOS ASAP, guys. Definitely worth the effort, just look at the changelog for the wlxxx driver tree already ..
In accordance with this, let me bestow upon you all the changelog for the wl12xx driver in linus' tree
Now for a little comparison. The kernel currently to my knowledge in the pandora image is 2.6.27, and here's the git tag for that release:
Code:
author	Linus Torvalds <torvalds@linux-foundation.org>	
Thu, 9 Oct 2008 22:13:53 +0000 (15:13 -0700)
In case you can't figure out where I'm going with this, let me lay it out for you. There are 3 pages of patches applied since 2009-05-06, where the driver officially entered mainline linux. That puts us at [holy-shit] patches applied to the driver the pandora image contains.
The way this usually works is:
  • Somebody develops driver in their own private tree
  • Same someone tries to get that driver committed to Linus' tree
  • Linus goes apeshit over every mundane detail said someone missed
  • Someone improves driver to match unrealistic standards
  • Linus commits driver to his tree
That means that OE probably (not definitely) included a driver that's severely sub-par linux standards and THAT is the driver our dear developers are currently trying to get to work.

Update the kernel and sort out the potential problems that gives instead of using a kernel so old it doesn't even have ext4 support yet please.

EDIT:
I should probably add that this is the EXACT same thing I experienced with my Acer Aspire One and kernel 2.6.27 back when I got it. The Aspire One uses an Atheros chipset in the 5000 series, which has 2 drivers. There's madwifi which is not part of the kernel but a separate and somewhat cumbersome thing to install, and then there's ath5k which had JUST entered at this point in time.
I tried using ath5k but had to give it up because it would either give me a horribly unstable connection at breakneck speeds, or a stable one at around 40kB/s (over 802.11g I might add). This meant I had to install madwifi which was a bother but I put up with it. Then 2.6.28 rolled around and holy-*******-**** did it get good from there. Everything worked as intended and I never had to bother with out-of-tree drivers again.

Lesson learned: updating the kernel can give impressive results
 
Last edited by a moderator:
EvilDragon said:
If you followed the blog, you knew there were problems with getting the driver to work correctly.
It does run, but it has a max peak of 45KB/s. The module itself does work though.
...
WiFi was the only thing where our couldn't get the driver fully working.
We hoped it would work out until now, and things got better. We can get stable speeds without packet loss, but we don't know yet why it's slow.
That's what I wanted to hear. Stable speeds without packet loss sound to me like the rest is a matter of handshake optimization, or possibly as silly as bus speed setting (been there...). 45 kilobytes per second is as fast as a PLIP link could go, or about four times as fast as a common null-modem could. It's not amazing today, but it's enough for sensible games and even telephony.
I'm not early in the queue, but I'm now firmly in the group who want the device, with or without dongle.
 
Last edited by a moderator:
zhasha said:
That means that OE probably (not definitely) included a driver that's severely sub-par linux standards and THAT is the driver our dear developers are currently trying to get to work.
Wrong, we're using the one from 2.6.34-rc with compat-wireless. Full 2.6.34-rc1 setup was tested and no improvement was found regarding wifi.

zhasha said:
Update the kernel and sort out the potential problems that gives instead of using a kernel so old it doesn't even have ext4 support yet please.
Believe it or not but .34-rc has certain issues than our current .27 setup doesn't, and there is no time to sort them now so close to release. And I think you can survive without ext4.

zhasha said:
Lesson learned: updating the kernel can give impressive results
This is not always the case.
 
Last edited by a moderator:
notaz said:
Wrong, we're using the one from 2.6.34-rc with compat-wireless. Full 2.6.34-rc1 setup was tested and no improvement was found regarding wifi.
Sorry, I was told you were desperately working off of 2.6.27 the last time I asked about it.

notaz said:
Believe it or not but .34-rc has certain issues than our current .27 setup doesn't, and there is no time to sort them now so close to release. And I think you can survive without ext4.
I have absolutely no doubt about that, but given the timeframe I'd say there's probably been plenty of time to switch upwards in the list, at least a version or 2. Keep in mind that .27 was released in October 2008. And as for me and ext4, I love it specifically because of extents, and it was introduced (not ext4dev, but ext4) in .29 I believe. Incidentally, that kernel also provided the final stability nail for the ath5k driver, so I have an unnatural attachment to it. Sure I can live without ext4, but having to reformat an ext2 card to ext4 later is going to be a hassle. I know you can just mount it as ext4, but my experience with that has been that it doesn't do jack for performance and kept on trucking with large indirect block tables instead of extents, which absolutely kills performance on my crappy hard disks at least.
tl;dr: my external hard disk went from 21MB/s to 30MB/s avg. write speed simply from switching from ext3 to ext4 (and runs at 12-15MB/s on FAT32/NTFS). I of course have no idea whether the SDHC card bus will limit my class 4 card or the card/filesystem will

notaz said:
zhasha said:
Lesson learned: updating the kernel can give impressive results
This is not always the case.
Hence the "can" clause.
 
Last edited by a moderator:
zhasha said:
notaz said:
Wrong, we're using the one from 2.6.34-rc with compat-wireless. Full 2.6.34-rc1 setup was tested and no improvement was found regarding wifi.
Sorry, I was told you were desperately working off of 2.6.27 the last time I asked about it.

For normal image at the moment, yes.
For WiFi testing, notaz did a small rootfs with a newer kernel to check that out.

notaz said:
Believe it or not but .34-rc has certain issues than our current .27 setup doesn't, and there is no time to sort them now so close to release. And I think you can survive without ext4.
I have absolutely no doubt about that, but given the timeframe I'd say there's probably been plenty of time to switch upwards in the list, at least a version or 2. Keep in mind that .27 was released in October 2008. And as for me and ext4, I love it specifically because of extents, and it was introduced (not ext4dev, but ext4) in .29 I believe. Incidentally, that kernel also provided the final stability nail for the ath5k driver, so I have an unnatural attachment to it. Sure I can live without ext4, but having to reformat an ext2 card to ext4 later is going to be a hassle. I know you can just mount it as ext4, but my experience with that has been that it doesn't do jack for performance and kept on trucking with large indirect block tables instead of extents, which absolutely kills performance on my crappy hard disks at least.
tl;dr: my external hard disk went from 21MB/s to 30MB/s avg. write speed simply from switching from ext3 to ext4 (and runs at 12-15MB/s on FAT32/NTFS). I of course have no idea whether the SDHC card bus will limit my class 4 card or the card/filesystem will

Don't worry, we'll upgrade to a newer version with a future firmware update. We want to have hardware accelerated movie-playing after all!

However, except for the hardware acceleration, the current OS is stable and runs pretty well (tested for over one month now!)
If we switch NOW, it might break things we couldn't fix until we assemble.
Now, what would happen if the first people get the Pandora with non-working WiFi so far and non-working OS? ;)

We'd rather have a solid base OS now and then concentrate on updating.
Everyone can help testing future firmware images, as you can boot them from SD Card.
So it shouldn't take too long until you will have a new kernel.

You can always compile a newer one for yourself and see if it works fine with your unit, too, if you want.
 
Last edited:
zhasha said:
I have absolutely no doubt about that, but given the timeframe I'd say there's probably been plenty of time to switch upwards in the list, at least a version or 2. Keep in mind that .27 was released in October 2008.
Looking back, it's easy to say "look at all the time you had", but they've been working to make it stable because it's been in a constant state of "coming soon". If you think you've only got two weeks to make something work, do you take the thing that's mostly working and add some extra features, or do you start with something entirely new which is known to be incomplete? That's a rhetorical question.
 
Last edited by a moderator:
Back
Top