Eds Status On The Pandora Os - Disheartening

[Trip]

The volume wheel was definitely asked for due to the 2X not having one.

I meant to mention this, but I don't consider it a very major decision.

So was a dedicated menu button.

Nor do I consider naming a button "menu", which is hardly a unanimous opinion anyway.

The clam shell is common sense.

Maybe when considering everything else, but even then more people wanted a sliding or swiveling design. OP says that such a design isn't an option, but with everyone else (big company or not) doing something like this I kind of question this.

The touch screen was asked for and bought because it didn't cost much more than the normal screen and it offered more choice. Craig was never really that keen on a touch screen IIRC.

Due to it having a touch screen, it also needed a stylus and a place to put the stylus.

No, craigix definitely wanted a touchscreen long before he mentioned anything here.

The battery wasn't originally going to be easily removable either, but M.Weston made it so after a lot of requests.

Another very minor design decision that was easy to change later.

Add WiFi to this list. It was a community request.

Not how I remember it. In fact, craigix believes so firmly in any new gaming handheld having WiFi that he thought Wiz was making a fatal mistake by not including it. It was definitely one of the features the device he envisioned (prior to announcing anything on these boards) included.

Yeah ok these might all be little things like you say, but the Pandora is is a collection of loads of little things. Without them it wouldn't have become what it is today.
Regardless of if you agree with me or not, this forum plus the other open source and gaming forums have all contributed to shaping what has become the Pandora handheld.
I'm not trying to take anything away from the hard work that Craig's done when I say that as he was the one that made all the final decisions etc. but to say that it was all just his idea is plain wrong.

 

[CCmachined]

Well, if you're REALLY desperate using WiFi and can't wait until we have SDIO properly working, you could always use a cheap WiFi stick

Not the best solution, but working.

1. I/We present awesome handheld with promised features to friends who have been laughing at me/us quietly for the past 2 years for waiting so damn long
2. Said handheld is using a stupid hacked on solution for promised functionality, despite OpenPandora and devs having had over a year to get it working
3. Barrels more laughter

:angry: . Fix it. Please

Not that I like to sound like a troll, but this will happen if this issue remains unresolved, to more than a few people I would imagine.

 

[juniorm33]

Solution:
Don't show it to friends until it's working how you like it. They've laughed at you up till now, just put up with it for a while longer. :lol:

You say fix it, you make it sound like their not trying, or it's way down on their list of priorities <_<

 

[WizardStan]

I don't think that's correct. The closed source driver would have the same SDIO problem that the open source driver has

From EDs most recent quote (see the quote thread) it would seem that the problem isn't really the SDIO dropping packets, it's a problem of sync. The WiFi is receiving data faster than it can push it down the SDIO line. It buffers the packets for as long as it can, but sooner or later the buffer fills and it needs to dump them.
The solution is "simple": make the SDIO go faster, or the WiFi chip go slower. From my very limited reading, the SDIO should be capable of 96Mbps (it's a 4 bit header, if I understand correctly), but that's the theoretical max, we'll probably never actually reach that. Not that we'd have to, since 802.11g tops out at 54Mbps. I wonder what speed they're getting now. Given the problems, it's probably best measured in Kbps rather than Mbps, so no doubt a lot of work (probably the kernel work MWeston and EvilDragon were talking about) needs to be done to get it up to speed.
The other option (as a temporary solution) is to find the magical setting on the WiFi chip that tells it how fast to go, and bring that way down to 1Mbps and see if it works any better: a slow connection because it is slow is a lot better than a slow connection because it drops packets. 1Mbps is pathetic for local connections, but it's really good for surfing (1Mbps means a 3 meg file downloads in about 25 seconds (more like 40 or 50 seconds because of overhead, but still way better than what EvilDragon is reporting now)). It's possible that even at 1Mbps they still get dropped packets, though, and it's always possible that I don't know what I'm talking about.

 

[Loonie]

Yeah, because we all bought a Pandora purely for connecting to WiFi networks.

 

[Exophase]

I'm not trying to take anything away from the hard work that Craig's done when I say that as he was the one that made all the final decisions etc. but to say that it was all just his idea is plain wrong.

I didn't say it was "all just his idea", I clearly said SOME of it came from outside contribution. But the notion that it was fully, heavily, or at all primarily designed by community input is a fantasy. The "collection of little things" you mention is just on the periphery and doesn't address the core decisions of processor platform/SoC, RAM, internal flash, case design, most of the controls, screen dimensions and resolution, battery dimensions and capacity, external interfaces, etc etc. Not to mention actual parts decisions and layouts. Seriously this all sounds like those Windows 7 commercials, you know, "it was my idea." I think people feel warm and fuzzy thinking that this is community designed because they happen to agree with the decisions that were made. If that gives anyone a good feeling then go for it, but IMO you'd be kidding yourself.

 

[VRAndy]

Yeah, because we all bought a Pandora purely for connecting to WiFi networks.

Uh, actually, many people are more interested in the "Computer" side of things than the "Game console" side of things.

Nowadays, a computer that doesn't go online is sad and lonely.

 

[Exophase]

From EDs most recent quote (see the quote thread) it would seem that the problem isn't really the SDIO dropping packets, it's a problem of sync. The WiFi is receiving data faster than it can push it down the SDIO line. It buffers the packets for as long as it can, but sooner or later the buffer fills and it needs to dump them.
The solution is "simple": make the SDIO go faster, or the WiFi chip go slower. From my very limited reading, the SDIO should be capable of 96Mbps (it's a 4 bit header, if I understand correctly), but that's the theoretical max, we'll probably never actually reach that. Not that we'd have to, since 802.11g tops out at 54Mbps. I wonder what speed they're getting now. Given the problems, it's probably best measured in Kbps rather than Mbps, so no doubt a lot of work (probably the kernel work MWeston and EvilDragon were talking about) needs to be done to get it up to speed.
The other option (as a temporary solution) is to find the magical setting on the WiFi chip that tells it how fast to go, and bring that way down to 1Mbps and see if it works any better: a slow connection because it is slow is a lot better than a slow connection because it drops packets. 1Mbps is pathetic for local connections, but it's really good for surfing (1Mbps means a 3 meg file downloads in about 25 seconds (more like 40 or 50 seconds because of overhead, but still way better than what EvilDragon is reporting now)). It's possible that even at 1Mbps they still get dropped packets, though, and it's always possible that I don't know what I'm talking about.

So I guess there's no "alternate path", just bad SDIO implementation? The TCP part of the stack allows "guaranteed delivery" and will effectively block by using acks. The problem is probably that it's timing out; the stack can't wait forever. Slowing down the network won't change the absolute time this taking.

If it's really 1200bps like ED said then I don't think it's worth even trying to "fix", focus energy on fixing the SDIO speed instead.

 

[emil10001]

I don't think that's correct. The closed source driver would have the same SDIO problem that the open source driver has

From EDs most recent quote (see the quote thread) it would seem that the problem isn't really the SDIO dropping packets, it's a problem of sync. The WiFi is receiving data faster than it can push it down the SDIO line. It buffers the packets for as long as it can, but sooner or later the buffer fills and it needs to dump them.
The solution is "simple": make the SDIO go faster, or the WiFi chip go slower. From my very limited reading, the SDIO should be capable of 96Mbps (it's a 4 bit header, if I understand correctly), but that's the theoretical max, we'll probably never actually reach that. Not that we'd have to, since 802.11g tops out at 54Mbps. I wonder what speed they're getting now. Given the problems, it's probably best measured in Kbps rather than Mbps, so no doubt a lot of work (probably the kernel work MWeston and EvilDragon were talking about) needs to be done to get it up to speed.
The other option (as a temporary solution) is to find the magical setting on the WiFi chip that tells it how fast to go, and bring that way down to 1Mbps and see if it works any better: a slow connection because it is slow is a lot better than a slow connection because it drops packets. 1Mbps is pathetic for local connections, but it's really good for surfing (1Mbps means a 3 meg file downloads in about 25 seconds (more like 40 or 50 seconds because of overhead, but still way better than what EvilDragon is reporting now)). It's possible that even at 1Mbps they still get dropped packets, though, and it's always possible that I don't know what I'm talking about.

There's a quote in the quote thread from MWeston saying that the wifi chip can deliver 4Mbps and the OMAP3 can handle 3Mbps max.

Regardless, my point remains that going to a closed source driver will likely not help anything since the problem is the SDIO. The SDIO issue is something that seems to be discussed independently of our wifi issue, therefore there is likely no 'simple' solution to this problem other than to fix the SDIO drivers.

 

[Loonie]

Uh, actually, many people are more interested in the "Computer" side of things than the "Game console" side of things.

Nowadays, a computer that doesn't go online is sad and lonely.

Um, actually, yes I know, I'm one of them.

There are plenty of things I can do with it that don't involve WiFi, and plenty of things that can be shown off to friends that don't involve WiFi. The way some people are carrying on, you'd think they dropped WiFi altogether or something.

 

[mindlord]

Exactly. I'm with you Loonie. I am more intersted in the "comuter" side of the Pandora as well. I'm certain that the Wifi issue will resolve smoothly. We've got some really talented folks around here. I don't think we will be without fullspeed Wifi for very long at all.

 

[Tor]

4 Mbps isn't much.. I'm a little bit surprised. And OMAP3 only 3Mbps? I haven't measured, but I was pretty certain the N900 could do much faster than that. I could be wrong of course. But BT on the N900 can do 3Mbps, and Wi-Fi on the 900 is supposed to be faster.

 

[Yod4z]

x264 is an H264 codec implementation. Mplayer on Pandora can play H264 but i think can play 720P or more vids but maybe 480p (DVD res).

MKV is just an contener you can put i it all you want (xvid, x264, ogg, ac3, mp3, playlist, images cover (jpg, gif...)...). MKV can be played on Pandora but some file use some heavy codec (like H264 720p)

 

[MWeston]

There's a quote in the quote thread from MWeston saying that the wifi chip can deliver 4Mbps and the OMAP3 can handle 3Mbps max.

BT is 3Mbps. Wifi is 96Mbps.

 

[Tor]

Ah, thanks, that makes more sense.

 

[emil10001]

There's a quote in the quote thread from MWeston saying that the wifi chip can deliver 4Mbps and the OMAP3 can handle 3Mbps max.

BT is 3Mbps. Wifi is 96Mbps.

Oh cool. Guess I misread your last post. Thanks for the correction.

 

[mali]

It must have been this post
http://www.gp32x.de/board/index.php?/topic/51819-quotes-thread-for-the-blog/page__view__findpost__p__819952

 

[WizardStan]

There's a quote in the quote thread from MWeston saying that the wifi chip can deliver 4Mbps and the OMAP3 can handle 3Mbps max.

I've confirmed the quote, and that seems really odd. The numbers don't add up. The SD bus has a 24Mhz clock. Even if they are only using a single line (which they might, the OMAP seems to support 4 bit but I didn't think to check the wifi chip), it should be theoretically capable of hitting 24Mbps.
I mean, I don't expect it to hit the theoretical max, but 1/8th of max is a heck of a drop off. Obviously I'm missing something.
Even so, 3Mbps is substantial, at least for internet connection. Slow for intranet setups, but I suspect memory or your SD card would be the bottleneck if you go any faster. So maybe 3Mbps really does make sense.

edit: Nevermind, I sat on that post too long making sure I knew what I was talking about. Thanks mate!

BT is 3Mbps. Wifi is 96Mbps.

 

[MDave]

Windows is definately better for normal users when you run it out of the box. However, you don't have the power to make it as flexible and optimized as a Linux system.

N-Lite

Customized Windows XP installation how you want it, so you can remove all the bloat and things you don't need before you even install XP.

There is also a Vista one.

 

[Loonie]

N-Lite

Customized Windows XP installation how you want it, so you can remove all the bloat and things you don't need before you even install XP.

There is also a Vista one.

I use that, it's good. You need to be careful, though, Windows is chocked full of so many stupid little dependencies, it's amazing what little thing can prevent stuff running or bring basic functionality crashing down.