Humpelstilzchen has quit [Ping timeout: 276 seconds]
norly has quit [Remote host closed the connection]
Humpelstilzchen has joined #neo900
vakkov has joined #neo900
vakkov has quit [Ping timeout: 256 seconds]
pabspabspabs has quit [Quit: Don't rest until all the world is paved in moss and greenery.]
vakkov has joined #neo900
norly has joined #neo900
vakkov has quit [Ping timeout: 264 seconds]
vakkov_ has joined #neo900
vakkov_ has quit [Ping timeout: 255 seconds]
vakkov_ has joined #neo900
vakkov_ has quit [Ping timeout: 250 seconds]
vakkov_ has joined #neo900
vakkov_ has quit [Ping timeout: 246 seconds]
vakkov_ has joined #neo900
vakkov_ has quit [Ping timeout: 272 seconds]
louisdk has joined #neo900
arcean has quit [Quit: App terminated!]
norly has quit [Ping timeout: 252 seconds]
Guest72593 has quit [Quit: Page closed]
vakkov has joined #neo900
vakkov has quit [Ping timeout: 246 seconds]
vakkov has joined #neo900
vakkov has quit [Ping timeout: 255 seconds]
louisdk has quit [Ping timeout: 258 seconds]
vakkov has joined #neo900
vakkov has quit [Ping timeout: 264 seconds]
vakkov has joined #neo900
vakkov has quit [Ping timeout: 264 seconds]
louisdk has joined #neo900
jonwil has joined #neo900
tuxmux has joined #neo900
tuxmux has quit [Quit: Quitte]
jonwil has quit [Quit: ChatZilla 0.9.91.1 [SeaMonkey 2.33.1/20150321194901]]
Pali has joined #neo900
sparetire_ has quit [Quit: sparetire_]
arcean has joined #neo900
drathir has quit [Ping timeout: 246 seconds]
paulk-collins has joined #neo900
drathir has joined #neo900
lobito1 has joined #neo900
lobito has quit [Read error: Connection reset by peer]
louisdk has quit [Ping timeout: 256 seconds]
arcean has quit [Quit: Leaving]
MonkeyofDoom has joined #neo900
mvaenskae has quit [Ping timeout: 264 seconds]
<ZetaR>
DocScrutinizer05: What would you consider to be a good value for leakage current on one of these ESD components.
<ZetaR>
Of course as low as possible, but how low does it need to be before other characteristics become more important.
<ZetaR>
Right now all of the ones I am looking at are 100nA max.
<ZetaR>
Some are less.
<DocScrutinizer05>
100nA is OK I guess. But shouldn't go any higher, not even by aging
<DocScrutinizer05>
100nA = 0.1µA which is already on the limit
<DocScrutinizer05>
we're frowning when we see quiescent or leakage currents in the µA range
<DocScrutinizer05>
they may be bearable when they are on active-while-powered signals, but we have a few rails and signals that should not draw _any_ leakage current since they'd do _all_the_time_ even with device powered down
<ZetaR>
This is 100nA max.
<ZetaR>
I can go down to 1-50nA max
<ZetaR>
i.e. the typical is usually unlisted, but when it is it is something like 1nA or 10nA.
<ZetaR>
So we have three main states right? In-use, standby, and powered-off.
<ZetaR>
The main issue AFAIK is the standby and powered-off current, since that is the states that the phone spends the most time in.
<ZetaR>
Is there a projected typical for the current draw in those states?
<ZetaR>
(total that is)
<DocScrutinizer05>
"as low as possible" ;-) Means in power off no more than a few µA total for the whole device. In "suspend" which is actually zero-clock on OMAP platforms, it should be no more than 2mA
<DocScrutinizer05>
however note that in zero-clock, most signal lines are at *high* voltafe since they have pullup R and OpenCollector outputs driving them
<DocScrutinizer05>
voltage*
<ZetaR>
Well, all of the diodes I am looking at are already 100nA max. I used this as a restriction when sorting products. I am trying to get a sense of how important a distinction between say 100nA max and 50nA max is compared to the values of other parameters of the diode (like clamping voltage).
<DocScrutinizer05>
in zero clock, CPU power domain is basically off, but complete IO power domain is on
<ZetaR>
Okay.
<DocScrutinizer05>
100 vs 50 is not that relevant
<ZetaR>
Sufficiently low to give diminishing returns?
<DocScrutinizer05>
please rephrase
<ZetaR>
100nA max (prob. 1-10nA typical) is low enough that reducing it further is not very significant to the current draw of the device.
<DocScrutinizer05>
yes
<ZetaR>
Okay. That is what I thought, but I just wanted to make sure.
<ZetaR>
I will have my component suggestions for you shortly.
<DocScrutinizer05>
there are maybe a very few signals we want to check closer and find something that's even better, but those are max 2 or 3 signals like powerbutton, VBAT, etc
<DocScrutinizer05>
:-) ta
<ZetaR>
Those are lines that have TVS.
<ZetaR>
So it is relevent to the component choice.
<ZetaR>
Especially VBat I am concerned about.
<DocScrutinizer05>
yes, VBAT is obvious
<ZetaR>
Diode I picked for VBat is <1nA typ and 50nA max.
<DocScrutinizer05>
that's good enough
<ZetaR>
Okay.
<DocScrutinizer05>
but keep in mind we always also need to check if the component is _sourcable_
<DocScrutinizer05>
there's a lot of nice components out there which are mere unobtainium or even vaporware
<ZetaR>
Everything is 5k+ stock at Digikey.
<DocScrutinizer05>
that's fine :-)
<DocScrutinizer05>
for VBAT_raw we prolly need two stages: TVS close to the batt connector, and OVP (huge Zener?) _after_ the polyfuse
<DocScrutinizer05>
I fight an uphill battle for TVS,in Openmoko as well as Neo900 project. Since the benefits are not immediately visible ;-)
<ZetaR>
That may not be a good idea. Polyfuse is to protect the TVSD.
<DocScrutinizer05>
or rather, the damage done when TVS is missing. It's happening at arbitrary time and usually not even directly associated with the missing TVS since the effects are subtle and weird
<ZetaR>
Yes.
<DocScrutinizer05>
er polyfuse is sloooooooow
<DocScrutinizer05>
and surges are sub-nanosecond range
<ZetaR>
TVSD protects the line, polyfuse protects the TVSD.
<DocScrutinizer05>
and even 5mm of trace might already be too high an inductance for proper ESD protection
<ZetaR>
If you put a TVSD before the polyfuse, it can be fried by extended overvoltage.
<ZetaR>
That is what proper layout is for: ensure the protected lines pass through the pads for the ESD protection.
<DocScrutinizer05>
nah, that TVSD in front of polyfuse will be a 50V or whatever type
<ZetaR>
Ah, okay, so I should look for a higher voltage one too.
<DocScrutinizer05>
yes, and that proper layout also needs to take care that no parallel or nearby traces might take the surge when it can't propagate to the TVS element from point of impact, due to long trace
<ZetaR>
Not sure if it is needed, though. The one I am looking at for VBat is 50A @ 5/50 ns and 3A 8/20 μs
<DocScrutinizer05>
thus you generally put ESD protection directly to the point where it would otherwise "enter the PCB"
<ilon>
damnit, I want 2 boards :(
<ilon>
How on earth am I supposed to justify the cost for this?
<DocScrutinizer05>
(3A 8/20 μs) doesn't help for polyfuse. it takes in the range of seconds to "blow", not µs
<ZetaR>
ilon: This may be your phone for 10 years or more.
<ilon>
ZetaR: Yes, thats also the reason why i would want to get two boards.
<DocScrutinizer05>
with this math, it's suddenly cheaper than any other device you could get
<ilon>
ZetaR: I dont want the radio to get into an unusable state as with my n900s
<ZetaR>
Exactly!
<ilon>
DocScrutinizer05: not really.
<ilon>
I tend to use devices until they are literally broken
<ilon>
and I do mean broken.
<ZetaR>
ilon: This is why I am looking carefully at ESD and surge.
<ilon>
ZetaR: Much appreciated
<ZetaR>
I am hoping to get a device that will last for 20 years.
<DocScrutinizer05>
ilon: (radio) won't happen, we take extreme care to avoid that known problem of N900
<ZetaR>
If I am careful with it.
<ilon>
I think i have 2 or 3 n900 with dead radios
<ilon>
which mean that I atleast dont have to get full devices
<ZetaR>
DocScrutinizer05: What is your estimate on the mean lifespan for the Neo900?
<ilon>
DocScrutinizer05: Thats a huge relief to hear, since thats been a worse problem than USB-port for me
<DocScrutinizer05>
the N900 "no SIM" problem is a combination of poor layout and flawed mechanical design
<ilon>
I don't think I've broken a single USB on my devices
<DocScrutinizer05>
I never did
<ilon>
they've got worn out, but still working tho
<ZetaR>
I filed the charger tabs and soldered the socket as soon as I got my N900.
<ilon>
DocScrutinizer05: I never had a no sim problem, my problem was that eventually my n900 would just silently drop calls
<DocScrutinizer05>
ZetaR: we plan for a 10 year lifespan, means all components shall survive a 10 year moderate to heavy use with a failure rate of no more than 5%
<ilon>
i.e behave as if i didnt have any service
<ZetaR>
DocScrutinizer05: Have you considered an active circuit instead of a polyfuse?
<DocScrutinizer05>
ilon: the problem usually is BGA solder joints popping open due to PCB bending by pressing kbd keys
<ZetaR>
(lifespan) That sounds great. Any idea what the failure rate would be after 20 years?
<DocScrutinizer05>
ZetaR: considered, yes. Found: no
<ilon>
DocScrutinizer05: Seems like a likely fault for me, since I used my n900 a LOT.
<ilon>
Also, currently trying to source more spare n900 for my private stash
<ZetaR>
(active fuse) Couldn't this be done with standart discretes?
<ZetaR>
standard*
<ilon>
realised some of my friends probably have their old ones laying around in a drawer :D
<DocScrutinizer05>
ZetaR: (20 y) no idea. It's no exact science since for that I'd need hard numbers. For example I just go for the 10 million rounds switches instead for the standard 1 million, etc
<ZetaR>
DocScrutinizer05: Do you have lifespan metrics for most of the individual components? I could try doing a probablistic derivation of the failure curve if I can get good data.
ruukasu has quit [Ping timeout: 258 seconds]
<DocScrutinizer05>
consumer grade commecial devices like N900 use switches that have 500,000 to 1mio rounds specified, and companies like Nokia save a few cents per device on them
<ZetaR>
But its not like the switches are fine for 499,999 presses and then break on the 500,000th press. What exactly does "good for 500,000 presses" mean then?
<DocScrutinizer05>
ZetaR: we need to scrutinize every datasheet to find out. Some datasheets have lifespan numbers, most don't (prolly since a ceramic capacitor or a resistor usually doesn't age at all)
<DocScrutinizer05>
it usually means exactly what I said above: x% dead after 500k rounds
<ZetaR>
Ah, okay. That should be pretty easy to do a projection using that.
<DocScrutinizer05>
bathtub curve
<DocScrutinizer05>
|__/
<ZetaR>
Well, if there is only one metric it would be a first-order approximation, not a bathtub.
<DocScrutinizer05>
| is "burn in", / is death by aging
<AndrewX192>
│11:38:51 +DocScrutinizer05 | ZetaR: we plan for a 10 year lifespan, means all components shall survive a 10 year moderate to heavy use with a failure rate of no more than 5% │ pigeons
<AndrewX192>
oops sorry
<AndrewX192>
middle mouse button strikes again
<ZetaR>
5% pigeon failure rate!
<AndrewX192>
yes pidgeons
<ZetaR>
(my thought when seeing that)
<ilon>
OT: Cant help but love the Maemo UI
<ilon>
I really miss it.
<ilon>
(just booted old device to try out CSSU)
<DocScrutinizer05>
welcome to the club! :-)
<DocScrutinizer05>
tbh many of the maemo4 UI aspects were even better than in maemo6 in my book
<DocScrutinizer05>
oops maemo5
<ilon>
Atleast now I have a working substitude device (LG G3 858 HK) until I (hopefully) receive my Neo900
<ZetaR>
DocScrutinizer05: The 5%/time metric can be used to derive a curve by assuming that the failures are a Posson process, and then these Posson processes can be aggregated to get a first-order approximation of the failure curve out to any arbitrary time. Of course, the failure curve might not be a Posson process but rather involve continuous degredation (which would require more research to model).
<DocScrutinizer05>
nah, it's usually the above mentioned |__/ bathtub curve
<DocScrutinizer05>
just the parameters of that curve change for different components
<DocScrutinizer05>
and *usually* you don't get to know about those parameters, even when manuf knows them
<DocScrutinizer05>
you simply get the "duration" to a e.g. 5% point in the right side increase of failures
<ZetaR>
Of course, which is why you can only do an approximation and you can't actually model the bathtub curve without guessing.
<DocScrutinizer05>
for some components the right side of curve may be very steep, for others it's quite flat and even increasing usage time to 2x is only increasing failer rate by a few percent, not to 100%
<ZetaR>
That sounds like the difference between cumulative degredation and a Posson process.
<DocScrutinizer05>
yes, and I hope my guessing is good enough for me and my customers ;-)
<AndrewX192>
is there a good source for N900 batteries these days?
<DocScrutinizer05>
fleabay
<ZetaR>
Do you prefer automative components when doing selections?
<DocScrutinizer05>
yes
<AndrewX192>
I have one dead N900 that I might neo900, the other still works
<DocScrutinizer05>
definitely
<ZetaR>
Okay, good.
<AndrewX192>
I got the iPhone about 7 months ago, haven't really looked back on the N900 since :(
<ZetaR>
I think the best way to ensure a long lifespan after component selection is to derate everything and carefully ensure that you don't leave those conditions. ESD is probably the most important thing but there could be others, e.g. putting series resistors on signal lines.
<Humpelstilzchen>
AndrewX192: just bought a PolarCell for mine, works fine so far
<DocScrutinizer05>
AndrewX192: there's a battery comparison thread on tmo, it's maybe outdated but still very useful. Generally there are a plethora of offers for BL-5J batts
<AndrewX192>
DocScrutinizer05: oh yes I remember that. I just imagine shelf life is a concern at this point
<DocScrutinizer05>
hmm, depends. LiIon has not that bad a shelf life *IF CHARGED*
<AndrewX192>
I have a stack of 8 so batteries I left at 60% not sure how well they'll do now
<AndrewX192>
(they are from 2012-2014)
<DocScrutinizer05>
however when stored uncharged, "it's dead, Jim"
<ZetaR>
Will the Neo900 be able to handle other battery chemistries?
<DocScrutinizer05>
umm, check the charger chip datasheet
<DocScrutinizer05>
afaik it *could*
<ZetaR>
Oh, duh.
<DocScrutinizer05>
but we don't support this anyway
<ZetaR>
((supercap)) What about making it a replacable primary battery?
<DocScrutinizer05>
nah!
<DocScrutinizer05>
way too large
<ZetaR>
IIRC there are ones that last for like 7 years.
<ZetaR>
Hmm, well you also do a replacable secondary but that might be harder to find (most seem to come welded to their terminals).
<ZetaR>
If someone is buying a Neo900 I don't think it would be too much to ask to open the case to replace a non-soldered component, as long as it ends up lasting a long time.
<DocScrutinizer05>
>> Measure the charge/discharge cycle characteristics after the 10000 cycles of charge/discharge at 25±5 °C with the charge/discharge cycle test condition for each part.<<
<DocScrutinizer05>
"non-soldered" means bulky battery tray. Can't do that
<DocScrutinizer05>
I hope for the "10l cycles" being honest
<DocScrutinizer05>
would at least mean 30 years
<DocScrutinizer05>
10k*
<DocScrutinizer05>
add on top increased temperature for still 10 years of lifetime -> my way to estimate Neo900 lifespan
<DocScrutinizer05>
still this battery is a component that's suspicious to me
<DocScrutinizer05>
but not suspicious enough to go for anything else that's even more of an unknown regarding lifespam and feasibility
<ZetaR>
I see. Okay.
<DocScrutinizer05>
I hope you appreciate my take on "life span policy in design"
<enyc>
=)
<enyc>
yes some of these new gadgets are horrible on lifespan!
<enyc>
too smal process and allsorts
<ZetaR>
I do very much. I think that operating conditions are very important too though.
<DocScrutinizer05>
of course
<enyc>
hrrm
<ilon>
Huh, I'm glad I had a backup of the flash files
<DocScrutinizer05>
I assume an average temperature of 40..45 centigrade in device
<enyc>
Are N900's known for just losing the ability to keep clock when battery removed? the internal RTC like battery just goes? are they hard to source / worthwhile at all?? at least they don't (seem) to end up leaking all over the place!!
<ZetaR>
DocScrutinizer05: I have finished my survey of approximately 800 TVSDs. My suggestions are: Littelfuse Inc SP3004-04XTG, Infineon Technologies ESD5V3U2U-03F H6327, and Infineon Technologies ESD5V3L1U-02LRH E6327.
<DocScrutinizer05>
enyc: yes, exactly
<DocScrutinizer05>
and some *do* leak
<enyc>
DocScrutinizer05: are their batteries hard to source? neo900 has something similar?
<DocScrutinizer05>
enyc: nope, I hope N900 is LiMG cell
<ilon>
DocScrutinizer05: power grid is THE hardest issue to get a reliable solution for in a home-hosted environment i would say
<ilon>
DocScrutinizer05: the only viable solution would be (obviously) your own UPSes, and then a cellular backup connection
<DocScrutinizer05>
well, there are UPS - which are responsible for 90% of mains related server outages ;-P
<ilon>
DocScrutinizer05: you didnt count for the connection to be working eh? :P
<ilon>
if the grid goes down, so does all the communications equipment in the building
<DocScrutinizer05>
with a decent server with redundant PSU you can go one direct line to grid, and one via UPS to a different line of grid
<ilon>
and your possibility to affect this is.. close to zip
<DocScrutinizer05>
yes, that's unfortunate
* DocScrutinizer05
remembers to feed the 12V supply to 1st level router (fritzbox) via PoE from location of 2nd level router and UPS
<DocScrutinizer05>
still pending
<ilon>
well, i used to have fallback 3g modem set up in my network at home
<DocScrutinizer05>
that's planned, yes
<ilon>
did i mention i dont really like to rely on people?
* DocScrutinizer05
neither
<ilon>
kinda of funny tho
<ilon>
like.. 5 years ago, my security routines would be considered thinfoil hat kind of paranoid
<ilon>
nowadays its almost common sense :D
<DocScrutinizer05>
nm
<DocScrutinizer05>
always like that
* DocScrutinizer05
wonders how long until the way we build Neo900 becomes state of the art
<ilon>
on the other hand, now look at me like some alien when i mention i run cpu-bound crypto instead of memory bound
<ilon>
:P
<ilon>
DocScrutinizer05: haha :P
<DocScrutinizer05>
seen the hw "sidechannel" exploit that works on some flawed sorts of RAM?
<DocScrutinizer05>
seems under very special circumstances you can get data out of RAM from an address that's not the data's genuine address
<DocScrutinizer05>
crosstalk between storage capacitor cells or somesuch
<DocScrutinizer05>
*very* weird thing
<ilon>
DocScrutinizer05: you mean the hammer attack?
<DocScrutinizer05>
basically no feasble exploit, but a flaw nevertheless. And one that shows that sometimes vulns can bite your rear from a very unexpected vector
<ilon>
bitflip hammering
<ilon>
whatever it what called
<DocScrutinizer05>
err hammer sounds about right, yeah
<ilon>
well, then there are workable exploits
<DocScrutinizer05>
:-S
<ilon>
albeit now in the wild afaik
<ilon>
and only works "good enough" on some vendors of ram
<MonkeyofDoom>
rowhammer, yeah
<ilon>
rowhammer
<ilon>
thank you
<MonkeyofDoom>
wild abstraction breaking
<ilon>
kinda funny concept
<ilon>
and the implementation to pinpoint addresses are just crazy beatyful
* DocScrutinizer05
AFK (who's laughing there?)
<ilon>
DocScrutinizer05: GL.
<ilon>
MonkeyofDoom: did you read some of the early takes on the task of finding the proper addresses?
<ilon>
MonkeyofDoom: that just did wild guesses and checked the timing or whatever it was
<ilon>
I just like reading the theory behind, so rarely remembers many details, since i have no practical use cases :/