Viability Of Psp Nubs

[tds48]

I was just wondering ...

Although the nubs are great (and mine work FINE) they do seem to be a touch fragile (the rest of the build is rock solid). If anything was to go first I would guess it would be these ..

So, thinking ahead, and perhaps stupidly - Can one do a Direct swop for PSP analogue nubs? I would imagine there would be three obstacles

1) HARDWARE - Are there the same connection points (common outputs), or would a bridging circuit be needed?
2) SOFTWARE - Depending on (1) I guess the os would need to be amended to cater for them? Or not if its a straight swap out?
3) Fitting them in the gap. I would imagine some sort of case modding to fill the void (PSP nubs seems smaller)

My understanding is that the PSP nubs are self learning

This discussion is THEORETICAL, and perhaps just plain ludicrous, it is Friday after all and my brains are fried!

I would love a pandorastein

I have my fire extinguisher ready [For the flames, not my unit burning ]

 

[Bofosho]

It is possible I guess but it would be a lot of hardware work.
Not 100% it would work but it should with a lot of patience and some knowledge/skill.
You would need to make a circuit for each analog.

It would not be the same as the Pandora analogs in many ways if it did work.

 

[OrR]

If you are worried, just get a few spare nubs once they become available as replacement parts?

 

[fearofshorts]

Yeah, just buy some spare Pandy nubs. But really, they're pretty hardy. I can't think of anyone who's managed to break their nubs yet (one nubbers don't count- the factory is what screwed up there).

 

[Exophase]

I don't know what the hardware layout of the PSP nubs is like, or even how it works electrically. It's probably a fairly simple mechanism, and with data that doesn't have to be generated very frequently the reasonable design decision on Sony's end would have been to make the CPU convert a pretty raw electrical representation of the nub state into coordinates.

What I do know is that this isn't how the Pandora nubs work - they're connected via I2C and while I don't know what the protocol is like exactly that guarantees you its some type of digital packet. It's 100% certain that whatever the Sony nubs output it's not going to be compatible. The only way around this is to add additional logic (probably a microcontroller) on top of the nubs to produce the Pandora compatible output or change the Pandora kernel to be compatible with PSP nubs. The latter is probably not a realistic option since it'd involve connecting them over some available interface instead of I2C, unless the PSP nubs are also I2C - and save for a few pads there's nothing you can route to. If they're outputting analog you're completely out of luck because there aren't any ADCs at all.

Personally I don't really like the nubs very much (yeah yeah I know, put down your pitchforks) and wouldn't mind them being replaced with something else one day >_>

 

[WizardStan]

The only way around this is to add additional logic (probably a microcontroller) on top of the nubs to produce the Pandora compatible output or change the Pandora kernel to be compatible with PSP nubs.

The controller for the nubs is actually on the board. The physical nubs themselves, the big things that are soldered to the board, if I understood correctly, are simple and analogue. The analogue signals are then converted by the chip on the board and communicated via I2C back to the OMAP. To that end, it might be possible to replace the Pandoras nub with the PSPs.

 

[urjaman]

The controller for the nubs is actually on the board. The physical nubs themselves, the big things that are soldered to the board, if I understood correctly, are simple and analogue. The analogue signals are then converted by the chip on the board and communicated via I2C back to the OMAP. To that end, it might be possible to replace the Pandoras nub with the PSPs.

I'd be mostly worried about a) layout of the PSP nub vs. of the pandora nub and B) are the electrical properties of the PSP nubs at all compatible with the pandora nubs? (eg. will the AVR FW just totally freak out from the inputs, or what?)

 

[fusion_power]

Are the Pandora Nubs really so terrible, that users already think about using the (also terrible) PSP-Nubs? h34r:
This really confuses me somehow.

 

[sebt3]

Are the Pandora Nubs really so terrible, that users already think about using the (also terrible) PSP-Nubs? h34r:
This really confuses me somehow.

Don't worry : they are way better than the psp nub

 

[MDave]

Are the Pandora Nubs really so terrible, that users already think about using the (also terrible) PSP-Nubs? h34r:
This really confuses me somehow.

Don't worry : they are way better than the psp nub

Only in comfort and the position they are placed on the console, otherwise they are not better then the PSP nubs.

 

[Exophase]

The controller for the nubs is actually on the board. The physical nubs themselves, the big things that are soldered to the board, if I understood correctly, are simple and analogue. The analogue signals are then converted by the chip on the board and communicated via I2C back to the OMAP. To that end, it might be possible to replace the Pandoras nub with the PSPs.

Are you sure about that? That makes even less sense than having a controller on the nub package, and is not really in line wtih what we've been hearing. Furthermore, it doesn't line up with MWeston's block diagram - NUB1 CTRL and NUB2 CTRL are completely self contained and don't have any analog signals going into them, suggesting that they include the nubs themselves.

If this is really what happened then it wasn't a good design decision IMO; I don't know what physical interface the nub controller takes but I'm sure having two of them are a bigger BOM cost than doing whatever interface logic straight to the OMAP and having it perform the conversion itself.. which we're already seeing would have been a better design for other reasons.

 

[urjaman]

Are you sure about that? That makes even less sense than having a controller on the nub package, and is not really in line wtih what we've been hearing. Furthermore, it doesn't line up with MWeston's block diagram - NUB1 CTRL and NUB2 CTRL are completely self contained and don't have any analog signals going into them, suggesting that they include the nubs themselves.

If this is really what happened then it wasn't a good design decision IMO; I don't know what physical interface the nub controller takes but I'm sure having two of them are a bigger BOM cost than doing whatever interface logic straight to the OMAP and having it perform the conversion itself.. which we're already seeing would have been a better design for other reasons.

The nub controllers are on the PCB; you can check it out here: http://urjaman.dyndns.info . See?
The omap doesnt have any ADC's that would fit the bill. The TPS65950 would have a MADC with 6 free channels, though it could be that those pins/channels were needed for other purposes. I must say that the cost of two ATmega8L's in an MLF package cant be very much. I'm guessing that the AVR's were chosen mostly because they can be used to hide some (sucky) proprietary algorhytm by the nub manufacturer (for poorly autocalibrating them), also they have a nice I2C interface, etc

 

[WizardStan]

Are you sure about that? That makes even less sense than having a controller on the nub package, and is not really in line wtih what we've been hearing. Furthermore, it doesn't line up with MWeston's block diagram - NUB1 CTRL and NUB2 CTRL are completely self contained and don't have any analog signals going into them, suggesting that they include the nubs themselves.

I'm about as sure as I am of anything else I say. Someone posted a problem they were having with their nub and went so far as to actually desolder and remove it, and took pictures of the pieces. No logic circuit on the nub itself, just resistive rubber and 5 legs, suggesting it's a pure analogue device. Someone (who may have been MWeston) then confirmed that the controller was on the PCB, not the nub itself. Unfortunately I don't have any idea where that thread is right now.
That doesn't automatically make it compatible with the PSP nub, of course, just that analogue vs digital isn't the reason.
If I recall correctly, the original plan had them using a standard nub and a ADC. Somehow they were sold on this new design which required a little bit more intelligence, hence the atmels. Just from looking at a picture of it (so I'm probably wrong) I would guess it actually uses 4 analogue signals: up, down, left, and right, all separate. That makes it a little more robust, and may explain how it's able to detect when someone is simply pushing on the stick without pushing it in any direction. It just seems neat to me. I eagerly look forward to being able to buy one, and hope that MWeston gets the rights to distribute the binary so I can one day replace my nubs firmware without fear of not being able to restore it.

 

[Exophase]

The nub controllers are on the PCB; you can check it out here: http://urjaman.dyndns.info . See?
The omap doesnt have any ADC's that would fit the bill. The TPS65950 would have a MADC with 6 free channels, though it could be that those pins/channels were needed for other purposes. I must say that the cost of two ATmega8L's in an MLF package cant be very much. I'm guessing that the AVR's were chosen mostly because they can be used to hide some (sucky) proprietary algorhytm by the nub manufacturer (for poorly autocalibrating them), also they have a nice I2C interface, etc

That's pretty disappointing. I doubt more than two of those ADC channels on the TWL4030 are used, although I'm not sure how many this interface needs (two each?).. At any rate, adding one chip with a multichannel ADC is cheaper than adding two; I haven't found the cheapest costs of discrete multi-channel ADCs but it'd be strange if you couldn't find one that was cheaper than a microcontroller. That parts look like they cost at least $2.00 even in pretty decent volume - that may seem negligible to us but given that I know MWeston has called components of that cost "very expensive" in conversations he's had with me before.

I'm kinda surprised that the choice of nub dictated the board layout to the extent of adding controllers, especially given that the nubs were changed at some point. It also means that a chunk of the money spent to develop the nubs (that afaik OP funded) went towards software development that could have been pretty easily done by the OP kernel team.

If OP is buying the nubs then I assume their electrical interface is fully documented. For the next Pandora they should definitely throw out the ATmegas and use some other interface, or at least consolidate two of them. The inability to reprogram without special hardware is a big problem - if I had to use a microcontroller interface for something then I'd use something programmable over a standard interface like UART, like STM32 Cortex-M3s (and probably communicate over the same interface), and barring that I'd make the code that can't be modified as simple and dumb as possible.

 

[urjaman]

I just wish that MW would have the rights to distribute the nub controller firmware (there's lock bits set in the atmels so you can't read them before erasing the entire flash). I'd so flash one of the Atmel's right away, if i knew i could reverse it. There's a header for that on the PCB. Also, if it is so that the nubs need 4 analog inputs/nub, the TPS65950 wouldnt have enough (it has 8, 2 are in use by default). Still 1 Atmel should have been enough. Well when i get fed up enough by my weird (one-nubbers bad one) nub, i might just take the plunge and atleast try to develop a better nub firmware (even if it were dumber, so that the calibration could be done even in normal userspace / or maybe in the kernel with some userspace hooks). And it would be easy to add firmware programming over I2C, they just didnt (ot atleast didnt document it).

 

[WizardStan]

MWeston once said something along the lines of there not being a lot of space left for fancy features like firmware reprogramming. I've got to wonder just how complex this calibration algorithm of theirs is that it takes almost 8K to implement.

 

[Exophase]

MWeston once said something along the lines of there not being a lot of space left for fancy features like firmware reprogramming. I've got to wonder just how complex this calibration algorithm of theirs is that it takes almost 8K to implement.

Not just that, but reserving a bootloader should take at most 4 64 byte flash pages.

 

[elwing]

The nub controllers are on the PCB; you can check it out here: http://urjaman.dyndns.info . See?
The omap doesnt have any ADC's that would fit the bill. The TPS65950 would have a MADC with 6 free channels, though it could be that those pins/channels were needed for other purposes. I must say that the cost of two ATmega8L's in an MLF package cant be very much. I'm guessing that the AVR's were chosen mostly because they can be used to hide some (sucky) proprietary algorhytm by the nub manufacturer (for poorly autocalibrating them), also they have a nice I2C interface, etc

hum, are you sure that it's the whole nub controller? I remember some talk about the nubs having a firmware...

edit: http://www.gp32x.de/board/index.php?/topic/47503-nubs/page__p__720042&#entry720042

 

[Exophase]

hum, are you sure that it's the whole nub controller? I remember some talk about the nubs having a firmware...

edit: http://www.gp32x.de...42&#entry720042

Yeah he's sure. It's those controller chips that have the firmware, not actually the nubs. We've all been confused :c

Okay lately just me. Drats.

 

[elwing]

Okay lately just me. Drats.

me too