Important color changes


Well this must be some kind of a record; for a news thread to go this off-topic this quickly. Probably something to do with most people having time off work and many of us are probably still drunk somehow, even if you haven't had a drop since finishing off the champers on boxing day lunchtime.
 
Sorry for an ignant post but where are we at with the replacement for the .pnd system? (dbp) Is it finalized?

I've made both .pnd and .deb packages and i really like the pnds. On the other hand, any work we do to make .deb packages could get used for debian-arm. Excepting stuff that is optimized to pyra hardware of coruse.
 
klapse said:
Sorry for an ignant post but where are we at with the replacement for the .pnd system? (dbp) Is it finalized?

I've made both .pnd and .deb packages and i really like the pnds. On the other hand, any work we do to make .deb packages could get used for debian-arm. Excepting stuff that is optimized to pyra hardware of coruse.
Click to expand...
Seriously you like making PNDs ? I HATE pxml to death. We have tools to make it bearable, sure. Yet the file format sucks b....
The dbp system is working nicely. dependencies are working like a breath. The file format is .desktop which is very close to .ini files, hence very simple to make and maintain. If you liked PNDs you'll love dbp for sure.

I doubt we'll make lot's of debs here. The debian community is doing awesome in the arm world. There's very few left to package in that format.
 
In Germany it's what we say, when we try to shatter glasses, and get drunk, if we don't succeed.
 
klapse said:
Sorry for an ignant post but where are we at with the replacement for the .pnd system? (dbp) Is it finalized?
Click to expand...

See https://pyra-handheld.com/repo/apps

The dbp format hasn't been officially released yet, unless I've not been looking, but a change now would probably call for all of those packages to need to be republished. I'd take the fact that it's in use means it's pretty much de-facto finalised.
 
levi said:
The dbp format hasn't been officially released yet, unless I've not been looking, but a change now would probably call for all of those packages to need to be republished. I'd take the fact that it's in use means it's pretty much de-facto finalised.
Click to expand...
Well, the thing is : it has been released so long ago that many forgot about it.
A possible PND-system replacement
and since that's part of the default pyra OS, I'ld indeed say that it's official :p
 
Does anyone else feel that the 1.35V rail doesn't seem well regulated at the point of load (looks like it drops down to ~1.25V not too far from where it is generated)? I haven't been following this project too closely, so I am admittedly not very familiar with the design--what else is powered by the 1.35V? What is generating the 1.35V (a buck in the TWL6030 or some other PMIC?)? Is there no remote sense option with whatever regulator is generating the 1.35V? I'm curious what those voltages would look like when you factor in variations (within spec) of the buck itself (assuming this PCB simulation assumed an ideal rail).

(I realize this project is very far along and there isn't time for major redesigns--something just caught my eye and I am here for discussion, not to suggest a redeisgn)
 
Last edited:
Azure said:
Does anyone else feel that the 1.35V rail doesn't seem well regulated at the point of load (looks like it drops down to ~1.25V not too far from where it is generated)? I haven't been following this project too closely, so I am admittedly not very familiar with the design--what else is powered by the 1.35V? What is generating the 1.35V (a buck in the TWL6030 or some other PMIC?)? Is there no remote sense option with whatever regulator is generating the 1.35V? I'm curious what those voltages would look like when you factor in variations (within spec) of the buck itself (assuming this PCB simulation assumed an ideal rail).

(I realize this project is very far along and there isn't time for major redesigns--something just caught my eye and I am here for discussion, not to suggest a redeisgn)
Click to expand...

The PALMAS (which is the power chip for the OMAP) constantly talks to the OMAP and regulates the power.

And no worries, the voltage IS allowed to drop at some areas. For the simulation, official OMAP5 IBIS files have been used. IBIS files (see information here: http://www.ti.com/lit/an/snla046/snla046.pdf) are files that are being used to make accurate simulations for the specific processor used.
So we could in fact see in the simulation, that all needed power supplies and connections are now within the accepted range in the datasheet of the processor - so everything is good here :)
 
EvilDragon said:
The PALMAS (which is the power chip for the OMAP) constantly talks to the OMAP and regulates the power.

And no worries, the voltage IS allowed to drop at some areas. For the simulation, official OMAP5 IBIS files have been used. IBIS files (see information here: http://www.ti.com/lit/an/snla046/snla046.pdf) are files that are being used to make accurate simulations for the specific processor used.
So we could in fact see in the simulation, that all needed power supplies and connections are now within the accepted range in the datasheet of the processor - so everything is good here :)
Click to expand...

Thanks for the reply! I guess my question stems from the variability of the 1.35V itself and what generates it. It must be an LDO or SMPS with finite spec windows. If this PALMAS chip is responsible for ensuring proper voltage regulation, is there a particular reason it presumably failed to regulate the voltage with the old PCB layout with the large IR drops (this is where the remote sensing question came from as I am curious where exactly is the voltage regulated to 1.35V?)? Is there a part # for this PALMAS chip?
 
Azure said:
Thanks for the reply! I guess my question stems from the variability of the 1.35V itself and what generates it. It must be an LDO or SMPS with finite spec windows. If this PALMAS chip is responsible for ensuring proper voltage regulation, is there a particular reason it presumably failed to regulate the voltage with the old PCB layout with the large IR drops (this is where the remote sensing question came from as I am curious where exactly is the voltage regulated to 1.35V?)? Is there a part # for this PALMAS chip?
Click to expand...

It's the TWL6040: http://www.ti.com/product/twl6040

The PALMAS didn't have any issues powering the OMAP5 on any CPU board version.
We were out of the suggested specs, but it was working.

The problem with the 4GB RAM was the power supply for the RAM.

Also, if traces are too thin, then you simply can't squeeze enough power through them, regardless how much you crank up the power source :)
 
EvilDragon said:
It's the TWL6040: http://www.ti.com/product/twl6040

The PALMAS didn't have any issues powering the OMAP5 on any CPU board version.
We were out of the suggested specs, but it was working.

The problem with the 4GB RAM was the power supply for the RAM.

Also, if traces are too thin, then you simply can't squeeze enough power through them, regardless how much you crank up the power source :)
Click to expand...
Are you sure it's not the TWL6030 or some other product? The TWL6040 appears to be for audio.

But back to the 4GB RAM--isn't the issue that your 1.35V rail dropped out of spec by the time it reached your RAM, but was still regulated to 1.35V at the source? Even if you try to minimize IR drops, fundamentally isn't there still a discrepancy between where this rail is regulated and what voltage is at the RAM? You mentioned the PALMAS chip is responsible for regulation--does it monitor the 1.35V at the source or does it monitor the voltage at the RAM?

I'm curious about the margining--it seems the lower spec limit for the RAM is 1.215V based on the graphic, and we're getting down to 1.245V in simulation with the improved layout? So, that's 2.4% (30mV) of margin--is that enough margin for component/manufacturing variability and any possible discrepancies between simulation & real-world? Does the 2.4% budget in transient response (is this a DC simulation? I'm curious as to how low those 1.245V nodes go in a transient response)? Are any of these traces accessible (perhaps with minor hacking if need be?) with a multimeter for correlation to simulation (I know the memory is a FBGA package, so probing the individual nodes is unrealistic, but I was wondering if there were some other point on the 1.35V rail that could be probed for correlation)?

Lastly (sorry for all the questions!), what determined the 1.35V +/- 10% spec in the graphic? My impression is that the Pyra uses DDR3L, which I thought has a lower spec of 1.283V?
 
Last edited:
second exodous said:
yeah, I don't see how I can use my Pyra as navigation on my bike.
Click to expand...
google "bag transparent bike map" I have one. It is open on one side though, for a paper map. But for a few drops (not a downpour) it works.

Bibifuret said:
Happy New Pyra Year !!!
Click to expand...
Wait... I thought it was
Code: 
++$PyraYear
and not
Code: 
$PyraYear= new PyraYear();
That seems inefficient.
 
You must log in or register to reply here.

Similar threads

EvilDragon
Finalizing the PCBs
12 13 14
Replies
261
Views
131K
ible
ible
EvilDragon
Power, Memory and Schematics
15 16 17
Replies
331
Views
102K
elvissteinjr
elvissteinjr
EvilDragon
It could be we're there!
6 7 8
Replies
156
Views
79K
rygD
rygD
EvilDragon
Waiting in October
8 9 10
Replies
187
Views
35K
rygD
rygD
EvilDragon
Last known issue fixed
5 6 7
Replies
136
Views
50K
rygD
rygD
Back
Top