<x29a>
DocScrutinizer05: any recommendation for alternative "power" batteries? for the longest battery operation?
<DocScrutinizer05>
hmm, see the tmo battery thread. It has some DIY mods to use larger batteries
<DocScrutinizer05>
for a given size like BL-5J there's not really much to gain over the standard 1350mA
<DocScrutinizer05>
maybe you can find 1600mAh now
<Wizzup>
x29a: not if you want it to fit in the case, heh
<x29a>
yeah, i was willing to go with a bigger battery lid
<x29a>
like the ones for the htc dream, doubled the thickness, but also battery lifetime
<DocScrutinizer05>
any claims of capacity >2000mAh are usually complete fake and the cell is a real 700mAh or less
<Wizzup>
there's a company that sells them even, check tmo thread
<DocScrutinizer05>
mugen
<Wizzup>
yeah.
<DocScrutinizer05>
I dunno if they still ship
<DocScrutinizer05>
would be interested in getting a 100 or some for our customers and hackers
<Wizzup>
last I checked it seemed like they did
<Wizzup>
I'm not too interested since I have a nice casing for my n900
<Wizzup>
fwiw the polarcell batteries are quite good
<Wizzup>
I'm happy with them at least
<DocScrutinizer05>
I got one in a used phone I received, and it was not behaving anymore. Worn out prolly
<DocScrutinizer05>
that's generally the problem: the higher the specific (per volume) capacity, the faster the cell builds up too high internal series resistance
<DocScrutinizer05>
aka wears out
<DocScrutinizer05>
which btw can often also cause massive problems with cell modem which needs high current at stable voltage, much more than the regular core system does
<DocScrutinizer05>
I've seen lots of phones all brands and builds telling "no signal" or the like when battery was old
<DocScrutinizer05>
the worn out polarcell still said it had 1500some mAh but went from 50% discharge (bq27200 meter) straight to system shutdown
<DocScrutinizer05>
alas the bq27200 doesn't care at all about series resistance of cell, neither about max load the system causes
<DocScrutinizer05>
it only counts Coulombs, and adjusts the meter at a certain lower and upper voltage
<DocScrutinizer05>
the batt meter in N9 is a completely different type iirc, which basically *only* checks voltage and impedance of the cell and from that does an educated guess of current charge as well as "age" of cell
<DocScrutinizer05>
if it wasn't for 100% feature completeness and compatibility to N900, I'd nuke the bq27200 and replace it by such an impedance meter
<DocScrutinizer05>
jury is still out on it if we can get *both* in parallel for Neo900
<DocScrutinizer05>
,ainly a question of available PCB real estate and I2C address conflicts
<DocScrutinizer05>
mainly*
<DocScrutinizer05>
and of course another 1.50 bucks for another component
<wpwrak>
measuring impedance sounds a lot more reasonable than all the other approaches i've seen so far
Oxyd76 has joined #neo900
norly has quit [Remote host closed the connection]
mvaenskae has joined #neo900
Humpelstilzchen has quit [Ping timeout: 272 seconds]
Humpelstilzchen has joined #neo900
ZetaR has quit [Quit: Page closed]
comradekingu has joined #neo900
<comradekingu>
Do i pay all costs on my side when sending the down payment?
<comradekingu>
I know some countries in the EU consider it on par with the cost for internal payment if you do half and half
louisdk has joined #neo900
<comradekingu>
there we go, payment sent
Pali has joined #neo900
<Kero>
DocScrutinizer05: curious, what's the (completeness/compatibility) requirement that a better (though different technology) battery meter cannot be used?
<comradekingu>
probably size issue and cost
* Kero
is refering back to something doc said 6 hours ago; that's not what I read in what he said; I'm more curious what kind of compatibility reqs there are [than hardware tech or price]
<Kero>
though size + cost is an argument in have *two* battery meters :)
<Kero>
*having
<freemangordon>
DocScrutinizer05: why do we need bq... gauge for maemo compatibility? Do I miss something?
Zero_Chaos has quit [Ping timeout: 250 seconds]
Zero_Chaos has joined #neo900
louisdk has quit [Ping timeout: 272 seconds]
louisdk has joined #neo900
mva has quit [Ping timeout: 276 seconds]
mva has joined #neo900
sparetire_ has quit [Quit: sparetire_]
modem has joined #neo900
louisdk has quit [Ping timeout: 252 seconds]
<DocScrutinizer05>
freemangordon: a lot of battery meter apps base on it
<DocScrutinizer05>
Kero: ^^^
<DocScrutinizer05>
and doesn't even CSSU status menu battery applet rely on it?
louisdk has joined #neo900
<Kero>
last thing I did with measuring a battery charge was w/ voltage (on an iPaq). not coulombs or impedance. no idea what the latter two would look like over discharge or lifetime.
<Kero>
ideally, the kernel (or a library) would provide some value derived from the underlying technology; that's what we put in /proc/apm back then. Nothing discoupled from the underlying technology invented since?
<Kero>
*decoupled
<Kero>
Neo900 users will expect a timely warning to do the 2-sec-battery-exchange, though!
<DocScrutinizer05>
Kero: for compatibility purposes it's irrelevant what could or has been developed since. We need to provide what maemo apps expect
<DocScrutinizer05>
you're right it's not a good situation when system shuts down hard
ruukasu has quit [Ping timeout: 240 seconds]
* Kero
does not expect an existing app in maemo for that neo900 feature. so we'd need some new software/daemon?/app anyway. should be really simple, assuming we can keep batteries (in different stages of their lifecycle) apart.
Xseba360 has joined #neo900
<DocScrutinizer05>
ordered shutdown of system on battery low is an existing and important maemo feature
Xseba360 has quit [Client Quit]
<DocScrutinizer05>
incl early warnings
<Kero>
02:24 <+DocScrutinizer05> the worn out polarcell still said it had 1500some mAh but went from 50% discharge (bq27200 meter) straight to system shutdown
<DocScrutinizer05>
and it's controlled by maemo status menu battery applet afaik, which in turn may depend massively on bq27200
<Kero>
so does that early-warning and shutidnw work?
<DocScrutinizer05>
not when battery is defect
<DocScrutinizer05>
nothing can warn you when battery voltage suddenly drops from 3.8V to 3.4V in no time
vakkov has joined #neo900
<Kero>
"worn out" does not sounds the sane as "defect" to me, esp in the context of using a different sensor that can measure the age of a battery. Or I misread what you said about impedance meters last night.
ruukasu has joined #neo900
<DocScrutinizer05>
to me "warn out" == "defect"
<DocScrutinizer05>
a battery that maybe can provide 1500mAh but only when you don't have loads > 100mA is "defect" for a cellphone that evidently needs 2A bursts getting powered by battery
louisdk has quit [Ping timeout: 276 seconds]
<DocScrutinizer05>
an impedance meter would detect that broken state of cell
<DocScrutinizer05>
a coulomb counter can't
<Kero>
ah, that clears things up
<DocScrutinizer05>
until the situation causes shut down
<DocScrutinizer05>
so in last maybe 10s (depending on load the system creates, could also be last 3 hours) the coulomb counter could tag that cell as "warn out and may go down any time without prior warning when modem draws 2A burst". But such tagging is pretty much useless since the system doesn't know if you change battery when system is shut down
<DocScrutinizer05>
in theory the software could use the bq27200 and other system resources to do sorts of impedance metering, which possibly is what BME does
<DocScrutinizer05>
sort of, at least
<DocScrutinizer05>
bq27200 can tell exact discharge current and batt voltage, so in *software* you actually sort of can calculate cell impedance
<Wizzup>
wrt battery meter and compat; if it is foss you can simply support both, right? please don't take this 'compatibility' thing too far :-) (if I understand it correctly)
<Wizzup>
I think most people will be very happy if most of maemo just works, if they need to fix a few apps or cannot use a certain battery app, they can just fix it
* Kero
is a software person. sounds interesting ;)
<DocScrutinizer05>
Wizzup: yes, Pali and colleagues *could* improve BME(-replacement)
<Wizzup>
just wondering, have you guys ever queried how many people really care about flash 9 still working (and the few other closed things)
<DocScrutinizer05>
Wizzup: nope, not really. Since it has little impact on design
<Wizzup>
because I personally envisioned / thought of maemo, foss, recompiled with more recent libs, with support for some/most applications in the manager
<Wizzup>
I'm not sure that the use of the '100% compatibility' is
<Wizzup>
or what it means, really
<DocScrutinizer05>
changing e.g. CPU would mean we not only need to recompile the system but also *all* apps, which is clearly not the idea behind the first Neo900 device. This is a challenge we might accept with STEP2 when community managed to get FOSS-fremantle running on a 100% compatible device
<Wizzup>
I am very happy with the cpu choice
<Wizzup>
in a few months I will have a lot more free time, so I may also be able to help out on the sw side
paulk-collins has joined #neo900
<Kero>
dunno about my future time. do know that I need a device to get my motivation high enough to work on SW.
* Kero
did a downpayment; eagerly awaiting what is coming!
Kabouik_ has joined #neo900
Kabouik has quit [Ping timeout: 272 seconds]
arossdotme has quit [Ping timeout: 272 seconds]
arossdotme has joined #neo900
<DocScrutinizer05>
well, with the current design (CPU etc) there is no question "how many people really care about flash 9 still working" since it simply will
<DocScrutinizer05>
:-)
<DocScrutinizer05>
just one of the major goals of Neo900 and fptf is *binary compatibility* so users can use the existing apps, no matter if FOSS or closed commercial ones
<DocScrutinizer05>
(think "angry birds")
<DocScrutinizer05>
this obviously rules out "recompile with more recent libs" when they are not ABI compatible
<DocScrutinizer05>
(generally libs *ought* to be ABI backward compatible anyway, alas often lib devels didn't ever hear of that)
<Wizzup>
DocScrutinizer05: it will simply work if you don't upgrade major maemo components
<Wizzup>
which I thought was the idea (eventually)
<Wizzup>
at least my idea
<Wizzup>
I don't see the point of a more recent phone with ever aging and vulnerable sw
<DocScrutinizer05>
CSSU so far managed to do all upgrades in a compatible way, I hope tehy will keep it this way
<Wizzup>
I do not think this is possible, unless you use very weird constructs
<DocScrutinizer05>
hmm?
<Wizzup>
more recent glibc will break old sw, new sw requires more recent glibc, etc.
<Wizzup>
and if you have no closed components, you can simple update/recompile them.
<DocScrutinizer05>
I don't see a single existing "new sw" for N900, and none for Neo900 either
<DocScrutinizer05>
of course you can create new software using the existing libs. I don't see any issue with that, it's been done all the time for maemo
<Wizzup>
What do you mean, "I don't see a single existing new sw"
<DocScrutinizer05>
anyway, ask freemangordon, he seems to be project chief of fptf. Neo900 UG and me only support community in that effort
<MonkeyofDoom>
the problem as I see it is that you can't use a new userspace (e.g. glibc) with the old (maemo) kernel on an N900, and you can't use some of the hardware with a new kernel
<MonkeyofDoom>
neo900 should fix most of that
<Wizzup>
MonkeyofDoom: there has been a lot of work on hardware enablement on n900
<Wizzup>
you don'y need neo900 for that
<Wizzup>
[that's also not the goal]
<Wizzup>
afaik
<MonkeyofDoom>
it's not the goal, but it's a nice side-effect
<Wizzup>
...
<Wizzup>
but the n900 mainlining work heavily supports the neo900 mainling work, and vice versa
<MonkeyofDoom>
true
<Wizzup>
anyway, that's not the point, so much
<MonkeyofDoom>
and there has been a lot of work on N900 driver support in the upstream kernel, but afaik it's still not feasible to do telephony and everything else with a new kernel
<Wizzup>
in the case of openssl you may be able to install several versions at the same t ime
<MonkeyofDoom>
I tried ofono numerous times and it was reboot roulette
<Wizzup>
MonkeyofDoom: I'm sure you know the link, but this indicates that data and speech should work
<DocScrutinizer05>
"fremantle" defines a userspace and a ABI which allows all apps in repos (and elsewhere) to run on the system. When you want to change that, don't call it fremantle, since it's evidently another iteration of maemo
<Wizzup>
DocScrutinizer05: right
<MonkeyofDoom>
Wizzup: yeah
<MonkeyofDoom>
camera is another pain point, I've only ever seen #00FF00 from it with newish kernels, but I haven't tried it since 4.0
<DocScrutinizer05>
CSSU and FPTF are about *fremantle*, so that's self defining regarding the above mentioned topics
<DocScrutinizer05>
aiui freemangordon said the new kernel he made work on N900 could actually run a fremantle compatible userland
<DocScrutinizer05>
iirc even incl "blob-libs" like for PVR
<DocScrutinizer05>
CSSU deplyed a bugfixed new version of glibc(?), I seem to have heard
<DocScrutinizer05>
if you want to swap glibc or whatever for a new incompatible version, you're free to do so in a not-fremantle fork any rime. You then need to recompile all FOSS apps in maemo community repo, and you can dump all your closed apps like angry-birds, naci aps, whatnot else
<DocScrutinizer05>
CSSU lib update is ABI compatible
<DocScrutinizer05>
s/rime/time/
<DocScrutinizer05>
s/naci/navi/
<DocScrutinizer05>
the beauty of Neo900+fptf is: there is a host of existing apps. Unlike it used to be for any other OS/distro for GTA02 Neo Freerunnor or any arbitrary other smartphone that came with a non-mainstream OS
ZetaR has joined #neo900
<Wizzup>
DocScrutinizer05: yes, that makes sense
<Wizzup>
It makes a lot of sense
<DocScrutinizer05>
particularly for a batch of devices as small as the one we plan to build
<DocScrutinizer05>
we never will find app devels that create a 500 or 1000 or more apps for a 500 devices userbase
<DocScrutinizer05>
thus re-using an existing app pool is vital for such project
vakkov has quit [Remote host closed the connection]
<Wizzup>
of course
<Wizzup>
I just thought that with some fremantle+1 you can still keep most apps
<Wizzup>
Most will likely 'just work'
<Wizzup>
I will think about this, and not distract further
<Wizzup>
my main concerns use/cases would just be: most recent openssh/openssl/gnutls and kernel, and that may be possible
<Wizzup>
otherwise in a chroot that just works too, of course
vakkov has joined #neo900
louisdk has joined #neo900
<ZetaR>
Hello all.
<ZetaR>
DocScrutinizer05: Did you get a chance to look at the information I emailed?
<DocScrutinizer05>
the mail looks good, will use it in next turn of schematics review/edit
<wpwrak>
what is actually the motivation for the changes ? i.e., in what regard are the proposed parts preferable over what we have now ? this small detail seems to be missing from the mail :)
<DocScrutinizer05>
supposedly needed "for new apps" - however any new app could use old libs as well
<Wizzup>
not if you do not want to compromise security
<Wizzup>
look, I am not saying new is always better
<Wizzup>
not at all
<Wizzup>
but some components (like xorg-server) are just nice to have newer versions of
<Wizzup>
also since so many holes in it have been plugged (but not backported of course)
<Wizzup>
I completely understand the contstraints, and how much time it would take
<Wizzup>
and I totally understand the current strategy
<Wizzup>
but when I'm talking about updated sw, I am not really interested in 'new apps', but in *updated* and *fixed* code
<Wizzup>
same for python, python2.7 is much nicer than python 2.5, etc
<Wizzup>
(again, this is not a complaint, just trying to explain why I think that at some point you want more up to date sw)
<Wizzup>
for example, new tls, openssh that can do djb's curve, etc
<ZetaR>
DocScrutinizer05: Now that the main TVS is done, I have been thinking about the TVS overcurrent problem that you brought up. I don't think that your suggestion of putting a higher voltage TVS in front of the polyfuse is feasible. If there isn't a significant impedance between the two diodes, the lower voltage one will activate first and reduce the voltage to its clamping level, and thus prevent the higher-voltage one from activating.
<DocScrutinizer05>
well, when it does, everything is fine. The primary TVS is only for the case when inductance and series Z to TVS/Zener after polyfuse is too high and thus a surce may jump to anpother trace instead of getting dissipated in ESD protection gear
<DocScrutinizer05>
surge*
<ZetaR>
Oh, well, that is a different problem. I thought you meant that this would be to reduce the current load on the primary TVS.
<DocScrutinizer05>
no, not at all
<DocScrutinizer05>
prmary TVS is for ESD, secondary (after fuse) is for OVP and reverse voltage
<ZetaR>
Okay, I misunderstood you then. Was there something you suggested to me that alleviates the overcurrent problem?
<DocScrutinizer05>
overcurrent problem?
<ZetaR>
Yes, we discussed how the polyfuse trip is too slow to protect the primary TVS in the event of an extended overvoltage.
<DocScrutinizer05>
the polyfuse is meant to cut out on overcurrent cause by: *) overvoltage *) reverse voltage *) circuit failure of any kind
<DocScrutinizer05>
for the first two points the secondary Zener is meant to cause overcurrent in polyfuse
<ZetaR>
Wait, what? How does it do that?
<ZetaR>
It is in front of the polyfuse, right?
<DocScrutinizer05>
since the Zener cannot dissipate overvoltage at arbitrary currents, the polyfuse also protects the Zener in that case
<ZetaR>
Oops, I thought you meant primary was after the polyfuse and secondary in front. Let me re-read.
<DocScrutinizer05>
we got a TVS in front of the polyfuse and a Zener behind it
<ZetaR>
Yes, I had just mixed up your use of primary and secondary.
<DocScrutinizer05>
ideally we'd use a diac of sorts instead of the secondary Zener
<DocScrutinizer05>
so it triggers to conduct at a certain forward voltage and then shorts and thus reduces voltage across the component, so all voltage drop is across the polyfuse
<DocScrutinizer05>
usually this circuitry is known as "crowbar"
<ZetaR>
So the component I suggested for this use does not fit with what you suggested: I selected an array with low clamping voltage, whereas the low clamping voltage would need to be across the crowbar, and the diode would need a high clamping voltage.
<ZetaR>
Except this is just the VBus line, right? Or is it all of the signal lines too?
<DocScrutinizer05>
only VBUS and BATT+
<ZetaR>
One of the solutions I was working with was actually a modified crowbar.
<ZetaR>
The idea is to have the TVS diode after a mutual inductor, and the mutual inductor induces a current in a thyristor, tripping it at a lower forward-drop than the TVS diode's clamping voltage.
<ZetaR>
induces it in the thyristor gate line*
<ZetaR>
It may be feasible to do this with just the inductor and thyristor as components, though it may require a resistor as well for the thyristor gate.
<DocScrutinizer05>
sounds interesting
<ZetaR>
It would mainly protect against large current pulses, whereas the typical crowbar application protects against overvoltage.
<ZetaR>
However, it is depended on finding a suitible mutual inductor.
louisdk has quit [Ping timeout: 272 seconds]
<ZetaR>
Max operating current in VBat and VBus is 3A, right? That is what the BQ24297 datasheet suggests to me.
<ZetaR>
Nope, not going to work. When I look at what is availible on Digikey, there are no small inductors that would fit the current requirements.
<ZetaR>
Everything >3A is >4x4mm.
<ZetaR>
>=3A*
<Pali>
whats problem with BME?
che11 has joined #neo900
mvaenskae has quit [Ping timeout: 276 seconds]
che11 has quit [Ping timeout: 255 seconds]
<DocScrutinizer05>
Pali: we discussed worn out batteries, and alternatives to bw27200 for batt gas gauge
<DocScrutinizer05>
bq*
<ZetaR>
DocScrutinizer05: I suspect the thing you are going to want before the polyfuse is a PCB spark-gap instead of a diode.
<DocScrutinizer05>
no, spark gaps are really poor choice. Not recommended anymore
<ZetaR>
Since when?
<DocScrutinizer05>
since ~ 20 years or so ;-)
<ZetaR>
I see them widely used in modern electronics.
<ZetaR>
The reason: you get them almost for free when you already have a PCB.
<DocScrutinizer05>
only in very poor designs trying to save pennies by tradeoff in quality
<DocScrutinizer05>
a psark gap is widely undefined parameters and introduces issues with creeping current
<DocScrutinizer05>
and you can't get spark gaps that operate at voltages < several hundred volts
<ZetaR>
I see it in designs that already have other forms of ESD/transient protection.
<ZetaR>
For the purpose of preventing the exact problem you mentioned above: unwanted arcing between traces.
<DocScrutinizer05>
on varnished PCBs spark gaps are not even in theory feasible
<DocScrutinizer05>
unless you keep the gap unvarnished
<ZetaR>
No. You just treat it as a solder pad.
<ZetaR>
It is just like a solder pad for an unassembled component, but shaped differently.
<ZetaR>
And because you don't have a component placed on it, you can put it very close to the connector.
<DocScrutinizer05>
yes, and it itroduces poor isolation between the involved signals
<ZetaR>
At 5V?
<DocScrutinizer05>
yes at any vltage
<ZetaR>
How so? We are talking about something operating in the kilovolt range.
<DocScrutinizer05>
some dust or dirt on PCB and you got a creeping current you don't want to see by any means
<ZetaR>
How is this different than the same thing occuring between pins on a package?
<DocScrutinizer05>
and due to the operation priciple of spark gaps the field gradient is high and that also means any electrolytic processes are critical when any humidity gets into contact with the copper
<ZetaR>
They are tinned, so it is the same as any other pin or pad.
<DocScrutinizer05>
no, the spark gap distance is significantly lower
<DocScrutinizer05>
sorry I won't discuss it any further, we had a decision on that
<ZetaR>
Eh, as you wish.
<DocScrutinizer05>
we won't use inferior solution "spark gap" when there are decent solutions like TVS
<ZetaR>
That is not the design case. The case is between TVS on the one hand and TVS *and* spark-gap on the other.
<DocScrutinizer05>
why do we need a spark gap where we already got a TVS for ESD?
<DocScrutinizer05>
also >>I suspect the thing you are going to want before the polyfuse is a PCB spark-gap ***instead of*** a diode.<<
<DocScrutinizer05>
also note that we don't want a *diode* but rather a symmetrical TVS like tranzorb or varistor, otherwise the polyfuse and crowbar wouldn't help avoiding comonent destruction on inverse polarity voltage
<ZetaR>
This is what I was thinking: spark-gap -> fuse -> TVSD, instead of TVSD -> fuse -> TVSD. The reasoning is this: If you are concerned about ESD being coupled to other lines before it can get through the fuse, etc. then you can create something that it will get coupled to first. For this purpose a spark-gap could be superior because, A: it can be deployed very close to the connector, while a diode requires a slightly farther placement,
<DocScrutinizer05>
the crowbar is no TVS, it's too slow for that purpose
<DocScrutinizer05>
it's strictly meant to act as OVP and RVP
<DocScrutinizer05>
in conjunction with the polyfuse
<ZetaR>
Varistor is probably slow enough that the crowbar will latch first, even with ESD that would jump to another trace.
<DocScrutinizer05>
meh, the one _you_ linked to has 1ns
<ZetaR>
Er, it depends on construction, actually.
<ZetaR>
I linked to a varistor?
<DocScrutinizer05>
1ns is not extremely fast but fast enough for this usecase where we also got EMI filtering and a polyfuse which introduces further slew rate mitigation
<DocScrutinizer05>
yes you did
<ZetaR>
I remember linking to Zener-based devices, not varistors.
<ZetaR>
Maybe I am confused about what you are saying.
<ZetaR>
I was specifically avoiding varistors because of the degredation and current leakage issues we discussed.
<ZetaR>
I think I may be misunderstanding the design criteria you are talking about.
<DocScrutinizer05>
littelfuse_mlv_mla.pdf
<DocScrutinizer05>
[2015-05-24 Sun 21:14:33] <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>
oops not that one
<DocScrutinizer05>
this one: [2015-05-23 Sat 21:54:30] <DocScrutinizer05> hmmm "repetitive pulse capacity" up to 10000 is promising on that one
<ZetaR>
Oh, that. That was the one I suggested replacing with Zener based solutions in the email.
<DocScrutinizer05>
this varistor look pretty good and I don't see why to replace it when we need a symmetrical TVS
<ZetaR>
I am very confused. What you are saying now sounds very different from what we were talking about a day or two ago.
<ZetaR>
Well this is what I thought was being said: varistors have current leakage degredation, and don't protect from reverse potentials; diodes would be more apropos for this application; steering offered additional benefits; some additional protection is needed on VBat and VBus because the diodes would overload before the polyfuse tripped with extended overvoltage.
<DocScrutinizer05>
err [2015-05-23 Sat 21:54:30] *is* 2 days ago
<ZetaR>
Yes, I mean now, not the quotes. I think I was misunderstanding your statement that you quoted as meaning "this is very good for a varistor, but we can do better with a different type of component".
<ZetaR>
Sorry if I confused things. I did that zener component search based on those assumptions.
<DocScrutinizer05>
the disgn goals for VBUS and VBAT are: symmetrical TVS at a clamp level of (8)15..20(50)V; OVP/RVP protection by polyfuse and crowbar circuit at +6V/-0.7V (0.7V won't fly since the polyfuse doesn't trip but then the crowbar won't escape blue smoke either. So as long as reverse voltage stays <-1V on internal side, it's OK for polyfuse to trip only at higher voltages causing higher voltage drop across the fuse)
<DocScrutinizer05>
OVP is slow by design and operation principle
<DocScrutinizer05>
RVP can't get done in TVS since that would burn out the TVS component
<ZetaR>
I see, I think. What I was thinking was SP3004 (my suggestion) + crowbar + polyfuse.
<ZetaR>
Littlefuse SP3004 was the 12V zener with steering diodes for signal lines.
<ZetaR>
(this is for VBus, one without steering for VBatt)
<ZetaR>
Isn't RVP also done by the crowbar?
<ZetaR>
Does crowbar=triac or does crowbar=SCR in this case?
<DocScrutinizer05>
yes, RVP shall also be done by crowbar, I specified that a few lines above
<ZetaR>
Oh, sorry.
<DocScrutinizer05>
we haven't decided on the crowbar design yet
<ZetaR>
I can do a search for suitable components like I did for the diodes, if you like.
<DocScrutinizer05>
we might search for a 2pole single SMD component acting like a diac/crowbar
<DocScrutinizer05>
NeoNDOWN PAYMENT NeoN bare board-34
<DocScrutinizer05>
+1EURDown Payment top up-3891
<ilon>
hmm, yes... should do down payment
panais has joined #neo900
norly has joined #neo900
mvaenskae has quit [Ping timeout: 246 seconds]
mvaenskae has joined #neo900
mvaenskae has quit [Ping timeout: 265 seconds]
rjeffries has quit [Ping timeout: 256 seconds]
sparetire_ has joined #neo900
louisdk has joined #neo900
mvaenskae has joined #neo900
<ZetaR>
I have done a quick napkin calculation: The energy released by passing 1A at 6V drop through a SOT-23-3 package for 1 second will raise its temperature by aproximately 1800*C, assuming the pins don't dissipate much of the heat during that time. A 0.4V drop will raise its temperature by about 125*C, bringing it past its maximum operating temperature.
<ZetaR>
This is also assuming that IC epoxy is similar in density and specific heat to FR-4.
<ZetaR>
This, and the lack of small components during my parts search for 1s overcurrent dumps, tells me that it is probably infeasible to absorb enough of a surge to trip a polyfuse using a small crowbar, without frying the crowbar.
paulk-collins has quit [Remote host closed the connection]
<ZetaR>
The equation ends up being roughly 300*volts*amps/seconds = degrees
<ZetaR>
Though, it is not really valid for anything but very short durations, because it doesn't account for heat transfer.
panais has quit [Ping timeout: 245 seconds]
Pali has quit [Remote host closed the connection]
louisdk has quit [Ping timeout: 256 seconds]
louisdk has joined #neo900
<ZetaR>
I don't understand why Farchild is encrypting their component docs.
skeuomorf has joined #neo900
panais has joined #neo900
louisdk has quit [Remote host closed the connection]