DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #qi-hardware
rjeffries has joined #qi-hardware
sandeepkr has joined #qi-hardware
sandeepkr has quit [Ping timeout: 248 seconds]
rjeffries has quit [Ping timeout: 246 seconds]
sandeepkr has joined #qi-hardware
sb0 has quit [Quit: Leaving]
pcercuei has joined #qi-hardware
sb0 has joined #qi-hardware
fengling has quit [Quit: WeeChat 1.4]
dandon has quit [Ping timeout: 260 seconds]
dandon has joined #qi-hardware
<kyak>
just discovered the NO_ACT option in irssi's ignore settings. How did i live without it?
<kyak>
for example, it can be set so that the [commit] messages from qi-bot are not ignored, but simply don't mark the channel as "Act:"
<kyak>
this way, i don't have to switch to the channel unless somebody actually said something :)
<larsc>
so basically never
<kyak>
no, i just had to switch because of your message! :)
<kyak>
but basically, yes -\
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #qi-hardware
sandeepkr has quit [Ping timeout: 246 seconds]
sandeepkr has joined #qi-hardware
sb0 has quit [Quit: Leaving]
FDCX has joined #qi-hardware
FDCX has quit [Remote host closed the connection]
FDCX has joined #qi-hardware
sb0 has joined #qi-hardware
FDCX has quit [Ping timeout: 276 seconds]
FDCX has joined #qi-hardware
dandon has quit [Ping timeout: 250 seconds]
aimg has joined #qi-hardware
kristian1aul has joined #qi-hardware
kristian1aul has quit [Client Quit]
kristianpaul has quit [Ping timeout: 244 seconds]
kristianpaul has joined #qi-hardware
kristianpaul has joined #qi-hardware
dandon has joined #qi-hardware
pcercuei has quit [Quit: bbl]
pcercuei has joined #qi-hardware
<wpwrak>
hmm, i could bemoan the injustice that all those well-paid quantum mechanics still haven't figured out how to make a decent ideal FET. e.g. with Rds(on) = 0 Ohm, very low Vgs(th), infinite Vgs(max) and Id, and of course no leakage whatsoever
<DocScrutinizer51>
well, they are pretty close
<DocScrutinizer51>
Rds_on of 5mOhm is alresdy reality
<DocScrutinizer51>
is*
<DocScrutinizer51>
Rds_on of 5mOhm id alresdy reality
<DocScrutinizer51>
ugh
<DocScrutinizer51>
low quiescent and creep currents are also normal, and voltages up to 50 are standard, more available
<DocScrutinizer51>
silego has some nice stuff with integrated charge pump
<roh>
be happy that there is some resistance left
<roh>
imagine it would be 0.. and your wires too... that would be nasty and one would have to invent something to limit powerflow ;)
<wpwrak>
Vgs often tends to be pretty low. e.g., i see a lot of FETs (mainly from vishay) that only tolerate 5 V
<DocScrutinizer05>
Vgs is not that relevant
<wpwrak>
it is if you connect this to VBUS ;-)
<DocScrutinizer05>
ohwell
<DocScrutinizer05>
then you need a p-fet instead a n-fet (or vice versa)
<DocScrutinizer05>
so you can connect source source to VBUS
<wpwrak>
well, that could get another volt or so, but adds operational constraints to the equation. better to pick a FET with enough headroom
<DocScrutinizer05>
on gate you do VBus || Vbus - 2V then
<wpwrak>
it's for suppressing the battery when USB is present, and for making VBUS compatible with logic levels for detection
pcercuei has quit [Ping timeout: 276 seconds]
<DocScrutinizer05>
check out the silego greenFET stuff, they have pretty nice chips
<wpwrak>
alas, the voltage ranges are such that i can't just tweak things with resistors
<DocScrutinizer05>
MOQ 10, iirc
<DocScrutinizer05>
< 100ct
<wpwrak>
more like MDQ 100. but way too greedy. as soon as you need a charge pump, you lose
<wpwrak>
(just checked the silego parts. alas, nothing that sticks out as being much better than the rest of the switches i've looked at.)
<wpwrak>
well, just a question of finding the right FET ... and then two more, for 2nd and 3rd source, just in case
<DocScrutinizer05>
hmm :-/
<DocScrutinizer05>
isn't that chargepump only drawing power when you have the FET open anyway?
<DocScrutinizer05>
oooh that's your problem, I see :-)
<DocScrutinizer05>
you'd need a chip that activates chargepump to go into switch-off state
<DocScrutinizer05>
you have no voltage regulation, right? How about an ideal diode in battery power?
<wpwrak>
(pump) yup :) in switch-off, i have all the power i want :)
sb0 has quit [*.net *.split]
FDCX has quit [*.net *.split]
_jungh4ns has quit [*.net *.split]
tumdedum has quit [*.net *.split]
mth has quit [*.net *.split]
sulky has quit [*.net *.split]
roh has quit [*.net *.split]
ChanServ has quit [*.net *.split]
ysionneau has quit [*.net *.split]
wpwrak has quit [*.net *.split]
jow_laptop has quit [*.net *.split]
DocScrutinizer05 has quit [*.net *.split]
pigeons has quit [*.net *.split]
Ornoterm1s has quit [*.net *.split]
DocScrutinizer51 has quit [*.net *.split]
Nik05 has quit [*.net *.split]
larsc has quit [*.net *.split]
uwe_mobile has quit [*.net *.split]
GonZo2000 has quit [*.net *.split]
mirko has quit [*.net *.split]
infobot has quit [*.net *.split]
kristianpaul has quit [*.net *.split]
eintopf has quit [*.net *.split]
aimg has quit [*.net *.split]
sandeepkr has quit [*.net *.split]
archang has quit [*.net *.split]
kanzure has quit [*.net *.split]
Luke-Jr has quit [*.net *.split]
uwe_ has quit [*.net *.split]
rodgort has quit [*.net *.split]
panda| has quit [*.net *.split]
dos1 has quit [*.net *.split]
kyak has quit [*.net *.split]
whitequark has quit [*.net *.split]
wej has quit [*.net *.split]
incomprehensibly has quit [*.net *.split]
solrize_ has quit [*.net *.split]
dandon has quit [*.net *.split]
woakas has quit [*.net *.split]
mazzoo__ has quit [*.net *.split]
newcup has quit [*.net *.split]
mithro has quit [*.net *.split]
qi-bot has joined #qi-hardware
sb0 has joined #qi-hardware
panda| has joined #qi-hardware
jow_laptop has joined #qi-hardware
<wpwrak>
well, could save some mOhm by putting in an inverter
<DocScrutinizer05>
yep, exactly
<DocScrutinizer05>
or even control the EN by MCU GPIO
<DocScrutinizer05>
if you got a spare one
<wpwrak>
i'd rather not have the MCU control its own power ;-)
<DocScrutinizer05>
you gotta detect USB VBus anyway, somehow
<DocScrutinizer05>
how do you do that?
<wpwrak>
i only have a valid USB_nSENSE if the MCU is up and has enabled a pull-up
<DocScrutinizer05>
well, then connect the EN in a way so it's active when MCU is down
<wpwrak>
tricky. what if the MCU gets confused while ramping up or down ?
<DocScrutinizer05>
gets confused?
<DocScrutinizer05>
btw we had same power control in that wikireader thing :-)
<wpwrak>
glitches, etc.
<DocScrutinizer05>
add a capacitor
<wpwrak>
yeah, in GTA01, too. and it produced very interesting effects ;-)
<DocScrutinizer05>
in wikireader it worked great
<wpwrak>
luck :)
<DocScrutinizer05>
nah, JR-design
<DocScrutinizer05>
;-)
<DocScrutinizer05>
know your CPU, add deglitching as needed, have a mech switch to bridge all the electronict to power up (MCU will be stable before you release that button anyway)
<wpwrak>
naw, let's keep things simple
<DocScrutinizer05>
how simple?
<DocScrutinizer05>
suspend mode for CPU?
<DocScrutinizer05>
there's hardly anything simpler than a pushbutton with a CPU GPIO controlled parallel FET
<DocScrutinizer05>
and you can expect <1uA quescent current, for sure
<DocScrutinizer05>
possibly rather in the low nA range
<wpwrak>
adding mechanical components is messy as far as i'm concerned
<wpwrak>
well, electromechanical
<DocScrutinizer05>
pushbutton switch from EN to VBAT, capacitor on EN to GND, resistor from EN to GPIO. Done
<DocScrutinizer05>
as long as you keep the pushbutton pressed, no worries about any glitches whatsoever
<wpwrak>
naw, let's design it such that it works without such patches
<DocScrutinizer05>
hmmm, when you hate that little hole for the switch button, how about using sth leete like e.g a spring+mass based g-meter - you whirl the dongle to switch on :-)
<DocScrutinizer05>
(I.E. >2g for long enough)
<wpwrak>
btw, you'll probably like the way i provide standby power: with silo caps next to the MCU, and an MCU-controlled FET before them, to isolate the MCU from the system voltage. power-up is still assured, irrespective of what the CPU tells the FET, through the body diode :)
<wpwrak>
(adding junk) anelok is a cost-conscious project :)
<DocScrutinizer05>
o.O nifty
<DocScrutinizer05>
sure, that's why I suggest to eliminate Q2
<DocScrutinizer05>
you prolly can eliminate a lot more of cruft when you switch complete power via EN
<wpwrak>
would be great if i can, yes. problem is a) polarity and b) possible voltage domain.
<DocScrutinizer05>
please elaborate, I'm thick
<wpwrak>
naw, i need Q1 in any case. especially since most boost converters don't block reverse current
<DocScrutinizer05>
I need a complete schematics
<DocScrutinizer05>
(don't block reverse) good point
<wpwrak>
yeah, update is still WIP. changing a bunch of things. and also drawing a nicer power tree
<DocScrutinizer05>
oh such fun to do a 20min real EE every 6 months
<DocScrutinizer05>
wish I could forget all the other mess with UG and do some for my device
<wpwrak>
hehe ;-)
<DocScrutinizer05>
how do you feed USB VBus?
<DocScrutinizer05>
directly to [powered]?
<wpwrak>
the joy to be "industriekapitaen" :)
<DocScrutinizer05>
FSCK!!!
<DocScrutinizer05>
Kapitaen of a dingi
<wpwrak>
[powered] is just an annotation, has no physical function
<DocScrutinizer05>
so to VBOOST then?
<wpwrak>
no, VBUS -> ESD -> VBUS_RAW
<DocScrutinizer05>
(makes more sense anyway)
<wpwrak>
then VBUS_RAW -> diode (to block reverse leakage from the regulator) -> LDO -> 3.3 V rail
<wpwrak>
ah yes, which is then = VBOOST
<DocScrutinizer05>
sure sure, VBUS_RAW fine, but where gets VBUS(_RAW) ... ahh wait you answered
<wpwrak>
before, i had something between 3.3 V and VBOOST. deleting the VBOOST label ...
pcercuei has joined #qi-hardware
<DocScrutinizer05>
so 3V3 is your main power rail, right?
<wpwrak>
yes
<DocScrutinizer05>
and how's battery -> 3V3?
<DocScrutinizer05>
it looks a tad ... complicated
<wpwrak>
battery -> stuff under discussion -> boost -> 3V3
<DocScrutinizer05>
a second booster?
<wpwrak>
no, U1
<DocScrutinizer05>
ooh, I gathered U1 is for USB VBOOST aka 5V0
<wpwrak>
noo !
<wpwrak>
i have an AAA primary cell. i need to boost it to 3.3 V
<DocScrutinizer05>
so VBOOST = 3V3 rail?
<wpwrak>
i don't supply USB host power. if you want USB host, welcome to the Y-cable
<wpwrak>
yes
<DocScrutinizer05>
please don't call it VBOOST :-) maybe it's just me, but VBOOST sounds like USB VBus hostmode
<DocScrutinizer05>
just call it 3V3
<wpwrak>
the label is already earmarked for deletion :) as i said, there was a FET after it (from an older design, with different characteristics), so it made sense to label the net. but now it's just 3V3.
<DocScrutinizer05>
oooookay. So let me suggest to use connect that 3V(3) LDO for VBus to VBat_safe
<DocScrutinizer05>
-use
<wpwrak>
that LDO output should be at ~3.3 V since this also supplies some 3.3 V domain items in the chip
<DocScrutinizer05>
mhm, well, the booster should still work fine with Vin==Vout
<wpwrak>
(says the documentation. not entirely sure how much abuse would be possible there.)
<wpwrak>
yes, but the MCU might hate having its 3.3 V items at VBAT ;-)
<DocScrutinizer05>
o.O
<DocScrutinizer05>
ooh#
<wpwrak>
besides, there may be non-negligible current between that and its real 3.3 V supply pins
<wpwrak>
yet another experiment i'd rather stay away from :)
<DocScrutinizer05>
add a FET like Q1 for VBus
<wpwrak>
i could of course add a dedicated LDO. might do that if i get really desperate ...
<DocScrutinizer05>
yet another one?
<wpwrak>
instead of the one in the MCU, so that it comes without strings attached
<DocScrutinizer05>
I already wonder if you could use a buck-boost converter instead of U1 and you'd not need any LDO
<DocScrutinizer05>
you know, a step-up/down that allows Vin<Vout<Vin
<DocScrutinizer05>
of course such a critter shouldn't be enabled 24/7
<wpwrak>
hast to be on all the time. the system can't run at battery voltage
<DocScrutinizer05>
you prolly couldn't find one that works at almost zero power consumption in low-load/idle
<DocScrutinizer05>
the system doesn't need to run all the time
<DocScrutinizer05>
which brings us back to the pushbutton
<wpwrak>
well, i could switch it in and out of battery change mode ...
<wpwrak>
but that adds a burden to an already tricky part
<DocScrutinizer05>
battery change mode?
<wpwrak>
when the MCU isolates itself and runs off silo caps
<DocScrutinizer05>
ohmy, wouldn't it suffice to write an instruction manual that says: "battery change only while attached to USB"?
<wpwrak>
;-)
<wpwrak>
might as well call it an iphone then :)
<DocScrutinizer05>
ummm
<DocScrutinizer05>
I don't get it why you must keep RAM content
<DocScrutinizer05>
or is there another reason to never power down the MCU?
<wpwrak>
yes, it's for the RTC
<DocScrutinizer05>
oooh
<wpwrak>
might also be nice to keep RAM, but i don't have a requirement for that at the time
<DocScrutinizer05>
well, as long as RTC is the only trouble, and that trouble is only during battery charge....
<DocScrutinizer05>
change, even
<DocScrutinizer05>
does the MCU have a real RTC, or is that a sw RTC?
<wpwrak>
loss of rtc can be painful. e.g., if using some time-based protocol
<wpwrak>
depends on the definition of "real" :) but there's a piece of silicon that says "RTC"
<DocScrutinizer05>
sure, your sw can detect loss of correct time, and make time setting mandatory on power-up then
<wpwrak>
eek
<wpwrak>
blinking 00:00, VCR-style ? :)
<DocScrutinizer05>
I'd consider that good enough when somebody really fails to change battery with USB attached, as recommended in manual
<DocScrutinizer05>
anyway, the RTC also needs 3N3 to keep time?
<DocScrutinizer05>
3V3 even
<DocScrutinizer05>
or does it have a proper BupBat input for a RTC-backup power supply?
<wpwrak>
no, that's why i can use the silo cap trick (or at least i hope it works, still to be tested)
<wpwrak>
nope, no separate power input
<wpwrak>
but the whole MCU can run at < 3.3 V
<DocScrutinizer05>
hmm, but you could use Vbat (1V) during normal device power-down
<wpwrak>
i need >= 1.71 V
<DocScrutinizer05>
:-(
<wpwrak>
it's always those little details :)
<DocScrutinizer05>
ffs
<DocScrutinizer05>
sorry, all fun has to end. I need dinner
<wpwrak>
hmm yes, me soonish, too
<wpwrak>
ah, now i remember what the problem in gta01 was. system power was controlled by the modem. cpu has a signal to the modem for the "power button". during cpu power-down, that signal became uncontrolled, causing the "power button" to be "pressed", which in turn told the modem to power up again ...
<DocScrutinizer05>
yeah, great¡ ;-D
<enyc>
funfun
<roh>
i remember some loop in i think gta02... where the suspend on the cpu glitched all gpios for reasons of not available versions of the pmu, which was fine for most of them besides the one line connecting to a transistor 'pressing' the 'test' button on the pmu of the modem. there were 2 of those transistors. one for the power button, one for test.
<roh>
so as soon as the cpu went asleep, the glitch happend and on the power button it was filtered out by hw debouncing, the test pin had none... ooops... so the modem woke up the cpu again via irq line
<roh>
i think the fix was to label the test-button-pressing-transistor 'dnp' ;)