What standards can the P2 follow?

[Binky]

Its simpler compared to scouring ebay in 10 years time trying to find a working battery for a pandora1.

Less simple than if ED or Link or whoever still stocks the original PB-4000-001 or a drop-in replacement.

Ideally, I'd like the P2's battery to be physically and electrically compatible with the P1's.

 

[_wb_]

The peripheral hardware required by android for their 'app store'

What exactly is that? Multi-touch screen? Accelerometer? Camera? GPS?

I'd say that accelerometer is nice to have because it's probably very cheap and small. Multi-touch is not essential for me, I'd prefer precision single-touch over finger-only multi-touch. But if both precision and multi-touch can be simultaneously achieved, that's fine. Camera is also not essential, but it would be a nice extra even if it's just VGA quality (that should be cheap enough) to be used for video calls. I wouldn't know where to place it though. GPS is probably too costly?

both the real and apple 3.5mm headset pinouts

How would this work? Two seperate headphone plugs? Or is there a way to make both work with the same plug?

0.1" headers

Sure, but no need to expose them, hardware tinkerers can open their case themselves. Let's try to minimize the number of holes in the case.

cases designed for the DS family

How would that work?

the same battery as the P1

Yes, and maybe if battery technology improves, in a later stage the battery can be replaced by something that packs more power in the same volume (and this would also benefit P1 owners).

The same stylus size as something else

Yes, I would even say just use an existing stylus, no need to make our own.

 

[Binky]

The peripheral hardware required by android for their 'app store'

 
What exactly is that?

>both the real and apple 3.5mm headset pinouts

 
How would this work? Two seperate headphone plugs? Or is there a way to make both work with the same plug?

cases designed for the DS family

 
How would that work?

http://source.android.com/compatibility/4.2/android-4.2-cdd.pdf

read section 7 - not sure how to interpret the "Should"s

----

Use a baby dpdt switch to swap the mic and earth lines

----

I mean protective cases, like the kind ED sells with a space for storing spare SD cards and the Pandora logo stamped ion the outside

 

[kuru]

you're suggesting we should waste PCB space with two different sockets for headphone and mic?

- Neelix

I'd suggest to waste space for a 2nd headphone connector, one in the front, on on the side to more effectively cater to the great portable sound machine that it would hopefully once again be. So you can slip it in your pocket and the headphone plug won't bend or be uncomfortable.

 

[Binky]

I suggest one headphone socket and a rocker switch (two buttons) on one end, and three buttons on the other.

The mapping of alll five buttons should be left to the user.

 

[bukkit]

What about the volume wheel?  Do we need it?

I love it. It's one of the things setting the Pandora apart from all those clumsy, often malfunctioning software sliders.

For me, it's almost as important as the clamshell design and the keyboard.

 

[_wb_]

I agree, hardware, continuous volume control beats software, discrete volume control any time.

The most annoying thing about discrete volume control (e.g. like the one on an iPad) is that the most silent volume (the first above "sound off") is sometimes still too loud - like how the dimmest display backlight setting on the Pandora can sometimes still be too bright (maybe we need a brightness wheel too?).

The most annoying thing about software volume control (besides that it is nearly always in discrete steps) is that there tend to be circumstances in which the control doesn't work or lags noticeably. The worst is when some misbehaving buggy game goes into an infinite loop while playing back annoying sound (e.g. loud white noise caused by some bug, or a repeating audio chunk), making the keyboard sufficiently unresponsive to make your frantic "WTF stop this shit! vol-down vol-down vol-down!" keypresses do anything at all.

 

[Neelix]

I'd suggest to waste space for a 2nd headphone connector, one in the front, on on the side to more effectively cater to the great portable sound machine that it would hopefully once again be. So you can slip it in your pocket and the headphone plug won't bend or be uncomfortable.

I can accept your argument for mounting the headphone socket on the side of the unit...  but  in that case I don't see why you would also need a second one on the front.

- Neelix

 

[Binky]

I think software volume control also tends to reduce the precision (and hence audio quality) of the sound.

Do DACs have volume control inputs? or take a digital audio steam of floats?

I would love a brightness wheel and a volume wheel.

would one of these make a good power/suspend switch?

--

@neelix: So the wire/plug/strain-relief doesn't dig into your hand while playing games with headphones on.

 

[Exophase]

I agree, hardware, continuous volume control beats software, discrete volume control any time.

The most annoying thing about discrete volume control (e.g. like the one on an iPad) is that the most silent volume (the first above "sound off") is sometimes still too loud - like how the dimmest display backlight setting on the Pandora can sometimes still be too bright (maybe we need a brightness wheel too?).

The most annoying thing about software volume control (besides that it is nearly always in discrete steps) is that there tend to be circumstances in which the control doesn't work or lags noticeably. The worst is when some misbehaving buggy game goes into an infinite loop while playing back annoying sound (e.g. loud white noise caused by some bug, or a repeating audio chunk), making the keyboard sufficiently unresponsive to make your frantic "WTF stop this shit! vol-down vol-down vol-down!" keypresses do anything at all.

 It sounds like your problem isn't with discrete steps in general but the selection of discrete steps on devices you've used. The great thing about system software on a device like Pandora is it can be changed by the user and is heavily impacted by user feedback.

Same with your problem with software controls not working reliably.. just because this has been the case for you doesn't mean it's an intrinsic flaw. If a kernel driver handles volume control via interrupts then it shouldn't be a problem.

The problem with a hardware volume wheel is it's hard to reproduce the setting exactly, there's no possibility for visual feedback on volume changes, there's no way to lock it out or bypass it, it has variability and cross balance problems and it can wear out over time causing crackling while changing volume. A good compromise, IMO, is to have a hardware wheel (either a continuous pot or a discrete encoder or something like that) that is monitored by low-level software. That way you can get feedback, lock out/bypass, and add filtering and calibration to deal with variability and wear problems.

I think software volume control also tends to reduce the precision (and hence audio quality) of the sound.

Do DACs have volume control inputs? or take a digital audio steam of floats?

I would love a brightness wheel and a volume wheel.

would one of these make a good power/suspend switch?

--

@neelix: So the wire/plug/strain-relief doesn't dig into your hand while playing games with headphones on.

There are audio codecs/DACs/whatever chips with volume controls, Pandora has one.. but I don't agree that software volume control hurts you in any appreciable/audible way. You can carry over whatever precision is needed out of the result of the multiplication. Audio chips like Pandora's take 24-bit audio directly, which is gross overkill for the type of performance (dynamic range/noisefloor/linearity/etc) of the device and limits of human hearing.

Brightness wheel seems excessive, can you guys really not think of better uses of board edge space than that? Brightness is controlled via PWM to the backlight so you're probably not going to want a direct circuit for that, if that's what you're thinking.

 

[Neelix]

I propose the manufacture of a right angle adapter for the headphone socket.  It would solve the problem without wasting PCB space and could be so generic you could sell it to the general public to use it with anything which uses a similar socket.

(Such may already exist,  but as yet I have been unable to find anything like this sold commercially)

- Neelix

 

[Franko]

I propose the manufacture of a right angle adapter for the headphone socket.  It would solve the problem without wasting PCB space and could be so generic you could sell it to the general public to use it with anything which uses a similar socket.

(Such may already exist,  but as yet I have been unable to find anything like this sold commercially)

- Neelix

I'm seeing a ton of these (if you "google"/search some)...try "right angle headphone adapter"....looks like there are many options...and one can orient it the way one wants to if the Pandora is in their pocket, for instance.

 

[Neelix]

Good point,  I had only been searching locally.    If ED can source a place to buy them by the hundreds at a reasonable price, he could sell them alongside the unit as accessories.

- Neelix

 

[_wb_]

I agree, hardware, continuous volume control beats software, discrete volume control any time.


The most annoying thing about discrete volume control (e.g. like the one on an iPad) is that the most silent volume (the first above "sound off") is sometimes still too loud - like how the dimmest display backlight setting on the Pandora can sometimes still be too bright (maybe we need a brightness wheel too?).


The most annoying thing about software volume control (besides that it is nearly always in discrete steps) is that there tend to be circumstances in which the control doesn't work or lags noticeably. The worst is when some misbehaving buggy game goes into an infinite loop while playing back annoying sound (e.g. loud white noise caused by some bug, or a repeating audio chunk), making the keyboard sufficiently unresponsive to make your frantic "WTF stop this shit! vol-down vol-down vol-down!" keypresses do anything at all.

 
It sounds like your problem isn't with discrete steps in general but the selection of discrete steps on devices you've used. The great thing about system software on a device like Pandora is it can be changed by the user and is heavily impacted by user feedback.


Same with your problem with software controls not working reliably.. just because this has been the case for you doesn't mean it's an intrinsic flaw. If a kernel driver handles volume control via interrupts then it shouldn't be a problem.


The problem with a hardware volume wheel is it's hard to reproduce the setting exactly, there's no possibility for visual feedback on volume changes, there's no way to lock it out or bypass it, it has variability and cross balance problems and it can wear out over time causing crackling while changing volume. A good compromise, IMO, is to have a hardware wheel (either a continuous pot or a discrete encoder or something like that) that is monitored by low-level software. That way you can get feedback, lock out/bypass, and add filtering and calibration to deal with variability and wear problems.

Good points. I suppose the hardware wheel with a low-level software monitor is the best solution indeed. I indeed don't have a problem with discrete in itself, as long as the selection of steps contains everything I want and it is sufficiently easy to go from any level to any other level. Typically you get something like 10 equally spaced steps, which is not enough resolution for me, and you only get a button for vol+1 and one for vol-1 (and maybe one for mute), which makes it tedious to go from one end of the spectrum to the other.

Brightness wheel seems excessive, can you guys really not think of better uses of board edge space than that? Brightness is controlled via PWM to the backlight so you're probably not going to want a direct circuit for that, if that's what you're thinking.

I agree, no need for a brightness wheel, but it would be nice to have a larger range of low brightnesses. I assume that this can be achieved more easily with OLED screens by the way.

 

[in3D]

I assume that this can be achieved more easily with OLED screens by the way.

I don't know about that. LED backlights use pulse-width modulation to change brightness, and OLED screens would probably work the same way. If that's true, very low brightness would have noticable flicker. What about ELP backlighting? Only seen that in car cd players...

 

[_wb_]

LCD screens like the one in the Pandora don't emit light, they filter the light provided by the (white LED) backlight. This is why black is not really black, since the filter can never really block all light from the backlight. This is also why black pixels and white pixels have about the same power consumption and max contrast is limited.

OLED screens don't have a backlight, the pixels themselves emit light. Black is real black, the power consumption of each pixel depends on its brightness, max contrast is actually infinity if you define it as (white lum / black lum) in a dark room (because of the division by zero); usually contrast is measured in a room with ambient light to avoid those divisions by zero.

I would assume you can get arbitrary low brightnesses on OLED screens, if necessary by just software-scaling the brightness of all pixels or by adjusting the gamma settings. That technique wouldn't really work with LCD because an all-black screen on the lowest backlight brightness setting may still be brighter than desired.

 

[monstercameron]

I agree, hardware, continuous volume control beats software, discrete volume control any time.

The most annoying thing about discrete volume control (e.g. like the one on an iPad) is that the most silent volume (the first above "sound off") is sometimes still too loud - like how the dimmest display backlight setting on the Pandora can sometimes still be too bright (maybe we need a brightness wheel too?).

The most annoying thing about software volume control (besides that it is nearly always in discrete steps) is that there tend to be circumstances in which the control doesn't work or lags noticeably. The worst is when some misbehaving buggy game goes into an infinite loop while playing back annoying sound (e.g. loud white noise caused by some bug, or a repeating audio chunk), making the keyboard sufficiently unresponsive to make your frantic "WTF stop this shit! vol-down vol-down vol-down!" keypresses do anything at all.

like the caanoo...

 

[TrashyMG]

I agree, hardware, continuous volume control beats software, discrete volume control any time.

The most annoying thing about discrete volume control (e.g. like the one on an iPad) is that the most silent volume (the first above "sound off") is sometimes still too loud - like how the dimmest display backlight setting on the Pandora can sometimes still be too bright (maybe we need a brightness wheel too?).

The most annoying thing about software volume control (besides that it is nearly always in discrete steps) is that there tend to be circumstances in which the control doesn't work or lags noticeably. The worst is when some misbehaving buggy game goes into an infinite loop while playing back annoying sound (e.g. loud white noise caused by some bug, or a repeating audio chunk), making the keyboard sufficiently unresponsive to make your frantic "WTF stop this shit! vol-down vol-down vol-down!" keypresses do anything at all.

like the caanoo...

You can have an all hardware push button volume control using digital potentiometers, but it would eat up about the same if not more space on the PCB as an analog wheel and would cost considerable more.. 

 

[Franko]

I agree, hardware, continuous volume control beats software, discrete volume control any time.

The most annoying thing about discrete volume control (e.g. like the one on an iPad) is that the most silent volume (the first above "sound off") is sometimes still too loud - like how the dimmest display backlight setting on the Pandora can sometimes still be too bright (maybe we need a brightness wheel too?).

The most annoying thing about software volume control (besides that it is nearly always in discrete steps) is that there tend to be circumstances in which the control doesn't work or lags noticeably. The worst is when some misbehaving buggy game goes into an infinite loop while playing back annoying sound (e.g. loud white noise caused by some bug, or a repeating audio chunk), making the keyboard sufficiently unresponsive to make your frantic "WTF stop this shit! vol-down vol-down vol-down!" keypresses do anything at all.

like the caanoo...

You can have an all hardware push button volume control using digital potentiometers, but it would eat up about the same if not more space on the PCB as an analog wheel and would cost considerable more.. 

No thanks.


I was just thinking of space and what we might be able to do without to free up some much needed room for other things.  I like the current volume wheel, and I know that it can be removed, and (the volume) be driven by the software...was just curious what you all thought about this particular feature.  Exo gave me the most detailed explanation and I appreciate that.  He's always a good read.