<wpwrak>
the boost regulator's enable input is a bit trickier than one would expect. only about 160 mV between rail and Vil/Vih. so significant leakage means that the pull-up has to burn a fair amount of power.
<wpwrak>
pull-up is R4, the transistor in question is Q1
<wpwrak>
before i had an n-FET, but they can leak a lot more than a BJT
<wpwrak>
(note that gate/base is uncritical in this case, since this is basically USB's VBUS)
luke-jr_ has joined #qi-hardware
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #qi-hardware
luke-jr_ is now known as Luke-Jr
sb0 has quit [Quit: Leaving]
sandeepkr has quit [Ping timeout: 248 seconds]
xiangfu has quit [Ping timeout: 276 seconds]
xiangfu has joined #qi-hardware
xiangfu has quit [Ping timeout: 264 seconds]
xiangfu has joined #qi-hardware
sb0 has joined #qi-hardware
xiangfu has quit [Ping timeout: 250 seconds]
sandeepkr has joined #qi-hardware
jwhitmore has joined #qi-hardware
wildlander has joined #qi-hardware
sb0 has quit [Quit: Leaving]
<DocScrutinizer05>
I'd use a cmos clock chip and a decent complete off
kilae has joined #qi-hardware
<wpwrak>
it's for disconnecting the battery when USB power is present ;)
<DocScrutinizer05>
why do you even need that?
xiangfu has joined #qi-hardware
<wpwrak>
because i won't want to empty the battery when i have usb power ?
<DocScrutinizer05>
but you empty the battery all the time when you don't have USB
<wpwrak>
well, yes, if i don't have USB power, the battery is all i have :)
<DocScrutinizer05>
so what's the use to save some 20 minutes out of a month?
<wpwrak>
some people may keep their anelok connected most of the time
<wpwrak>
some won't, of course
<wpwrak>
the latter group will have to buy batteries more often :)
<DocScrutinizer05>
well, I just can repeat myself: A cmos clock and goldcap backed up by battery, a decent powerbutton, and device getting powered up permanently when on USB
<wpwrak>
supercap problems, no thanks ;)
<wpwrak>
besides, they're huge
<DocScrutinizer05>
o.O
<wpwrak>
and probably rather expensive, too
<DocScrutinizer05>
do the math, then reject
<DocScrutinizer05>
you need a goldcap for how much? 5 minutes?
<DocScrutinizer05>
you prolly can use a tantal capacitor
<wpwrak>
the problem isn't time but that supercaps don't start cheap. the cheapest is about USD 0.50 and is large
<wpwrak>
besides, such a circuit would complicate time management quite a lot. especially for RF.
<arossdotme>
total cost of ownership? $0.50 id say is cheep compared to buying a 2rd batt
<arossdotme>
to replace the original dead one in the future
<wpwrak>
don't forget that RF has timekeeping as well. and i will not necessarily have control of that stack. so even if i manage to "migrate" my RF time between chips, that may be of no use and i'd have to keep the system on regardless
<DocScrutinizer05>
you completely lost me
<wpwrak>
besides, i may have to turn off the boost regulator also to prevent reverse charging. data sheet isn't entirely clear on that.
<DocScrutinizer05>
when you can't control the sytemtime in parts of your system, then you are doomed anyway if you depend on that time, no?
<wpwrak>
the part that controls it is also the one that depends on it. all i have to do is ensure that it's powered
<DocScrutinizer05>
that's why I said "use a decent power button that triggers a `keep on` circuit"
xiangfu has joined #qi-hardware
<DocScrutinizer05>
sorry, I can't follow
<wpwrak>
but that's something that's "always on" ... (BTLE)
<wpwrak>
i do have a mechanical power switch for it (rfkill) if you don't want to use it. but it you use it, it has to be on.
<wpwrak>
(follow) at least initially i don't control the firmware inside the BTLE chip. so i can't make it use fancy time migration schemes. i don't even know if if they could be implemented in a useful way. communication protocols are not afraid of using pretty demanding timing.
<wpwrak>
so without prior solid R&D i wouldn't want to depend on such a scheme
xiangfu has quit [Ping timeout: 246 seconds]
xiangfu has joined #qi-hardware
<DocScrutinizer05>
you already depend on such a scheme for battery swapping
<DocScrutinizer05>
where your complete system loses time
<DocScrutinizer05>
you need to set time in BTLE when iuser turns it on with switch, no?
<DocScrutinizer05>
now extend your "battery swapping" time to days, with a decent power-off scheme, and resume from "battery-swap" off with the pretty nice time from CMOS RTC
<DocScrutinizer05>
heck, you even could use the RFKILL switch for powerswitch instead
<wpwrak>
for battery swapping, i depend on something that's inexpensive and reasonably simple. and RF will inevitably go down when you swap the battery. no problem with that.
<DocScrutinizer05>
so which problem with a cmos clock instead?
<wpwrak>
rfkill has a specific purpose
<wpwrak>
$$$ and doesn't add anything useful
<DocScrutinizer05>
huh??
<DocScrutinizer05>
do your math
<DocScrutinizer05>
you're fighting 5 dozen problems that arise from trying to keep MCU always powered
xiangfu has quit [Ping timeout: 244 seconds]
<wpwrak>
as soon as RF enters the picture, i need to have power always anyway
<DocScrutinizer05>
huh? why?
<wpwrak>
because of timing. RF sleeps, then wakes up, briefly does its thing, then sleeps again. all this with precise timing.
<DocScrutinizer05>
I guess I missed to read the product reqirement spec
<DocScrutinizer05>
I wouldn't want to carry an always-on RF device with me
<wpwrak>
you have rfkill to turn that off :)
<DocScrutinizer05>
s/rfkill/power/
<wpwrak>
no. rfkill is specifically for the tin hat faction. kill RF, let you use anelok.
<DocScrutinizer05>
ohmy
<DocScrutinizer05>
yeah, evil anelok could be rooted so it enables RF in software when device powered on, even when code says it shouldn't
<wpwrak>
exactly. and don't forget that, at least for some time, i don't control the firmware in the RF chip.
<wpwrak>
much like we don't control the fw in the neo900 modem
<wpwrak>
but that rfkill switch goes a bit beyond what we do there and is really impossible to bypass
<DocScrutinizer05>
so? we don't have a hw power switch for Neo900 modem either
<wpwrak>
yes, anelok doesn't have that vulnerability :)
<DocScrutinizer05>
when you system in control gets hijacked, there's nothing you can do except shut it down completely
<DocScrutinizer05>
ROTFL
<DocScrutinizer05>
please provide a product requirements spec, with usecases
<DocScrutinizer05>
(whn your system in control...) IF you even notice that rogue condition
<wpwrak>
is the "secure core" gets compromised, you obviously have a problem
<DocScrutinizer05>
there's no use in having a hw switch in your PCs internet cable, to mitigate virus attacks
<wpwrak>
that rfkill also has some marketing dimension. it's an intuitively safe way to do it.
<wpwrak>
some people airgap their computers
<wpwrak>
and of course, that means no wireless either :)
<DocScrutinizer05>
please provide a product requirements spec, with usecases
<wpwrak>
anyway, no supercap, no clock chip, no I2C bus
<wpwrak>
i don't have a finished document of that sort. but you can find most of the relevant information on the list
<DocScrutinizer05>
yeah, rather FETs and BJTs and buffer caps and always-on boost converters and pullups at the cliff of nA (my DMM ends there) and timekeeping with untuned crystals and battery swapping tricks and
<DocScrutinizer05>
I'd do a proper I2C rather, every day
<DocScrutinizer05>
to a 50ct RTC chip, with a 30ct cap as bupbat
<DocScrutinizer05>
and shut the whole rest down when not iused
<wpwrak>
more like 50 cts. or 80 cts if you want specs that say that you can actually solder it.
<DocScrutinizer05>
you save that easily on other components that are not needed anymore
<DocScrutinizer05>
well, almost. When you count in assembly and complexity and design, more than compensate it
<DocScrutinizer05>
when user keeps anelok on USB 99% time, just don't 'switch it on' since it's always powered when on USB
<DocScrutinizer05>
nuke your whole USB-shots-dwon-battery
<DocScrutinizer05>
shuts-down even
<DocScrutinizer05>
battery swap? nuke the whole nifty RC timekeeper stuff
Luke-Jr has quit [Excess Flood]
<DocScrutinizer05>
forget about quiescent currents completely since the device is 99.9% time off
<DocScrutinizer05>
forget RFKILL since you shut down the complete device
<DocScrutinizer05>
yeah you would need sw driven 'RFKILL' then for the 3 minutes you want to use anelok UI without BTLE
<DocScrutinizer05>
I guess even tinfoil hats can cope with that
Luke-Jr has joined #qi-hardware
<DocScrutinizer05>
if they *realy* are afraid RF could be infested with weird hacks or flaws, they won't switch on anelok in a security sensitive environment and situation, before they have inspected system state to make sure there is no such hack or flaw
<DocScrutinizer05>
you already got a RF-LED I've seen. Should be just good enough togethher with a sw-controlled power switch
<DocScrutinizer05>
and you can be absolutely sure your device will keep accurate time and not eat more than 500nA from battery when powered down
<DocScrutinizer05>
pretty simple to evaluate and verify from schematics, could prolly even get done algorithmically
<wpwrak>
the rf led is for development. no really mean to be seen from the outside
<wpwrak>
only the sMCU LED is intended to be visible
<DocScrutinizer05>
hmmm, how about you make that a dual-color LED then?
<DocScrutinizer05>
<1mA for blue is pretty much sufficient. Allow users who are more interested in a RF-always-on than a "I see RF is on" to break a 0R with a toothpick, to disable the LED
<wpwrak>
hmm, nasty trace, going all across the board. it would also leave the 3rd LED still internal. so for some development you'd still need to remove he case
<DocScrutinizer05>
err, there are 3-color LEDs ;-)
<DocScrutinizer05>
aka RGB
<wpwrak>
you certainly have a taste for expensive components :)
<DocScrutinizer05>
decent design sometimes needs decent components
<wpwrak>
i'd be more concerned about fringe features getting way too much weight :)
<wpwrak>
lemme see how RGB vs. 3 LEDs compare, cost- and sourcing-wise ...
<wpwrak>
leds leds, 13 cents, all three of them. sourcing obviously not an issue. now, rgb, 3.3V compatible, ...
<wpwrak>
hehe, there's a red, UV, yellow-green tri-color LED ;-)
<wpwrak>
yes, but that's abs max, not the test current for Vf
<DocScrutinizer05>
aah k
<DocScrutinizer05>
I guess the LED is rather 'boring', I'd rather discuss the RTC ;-)
<DocScrutinizer05>
Vmin 0.9V, Vbat 1.2V, that's a 0.3V discharge at 500nA
<DocScrutinizer05>
500nA * 240s / 0.3V
<DocScrutinizer05>
~500E-9 * 240 / 0.3
pcercuei has joined #qi-hardware
<DocScrutinizer05>
~500*10**-9 * 240 / 0.3
<infobot>
0.0004
<DocScrutinizer05>
400uF
<wpwrak>
no need to over-optimize leakage. the AAA will chemically leak after a few years anyway, so a few uA are fine.
<DocScrutinizer05>
(400uF) for a 4 minutes. So much about "goldcap price and problems)
<DocScrutinizer05>
s/)/"/
<wpwrak>
and your RTC is still incompatible with BTLE. plus it doesn't accomplish proper battery separation on USB. you could do that by software, but that's a high-risk proposal, given that you'd have quite different threshold voltages
<DocScrutinizer05>
aha
<DocScrutinizer05>
well, you really don't see what I suggest
<wpwrak>
naw, the current design is nice. enough. if someone shows me that BTLE can be made to work with such an external clock chip, then i might consider it for some future revision, but for now, i'd play it safe.
<DocScrutinizer05>
how is a RTC incompatible where a systemclock with RC based guessing of power-down time isn't ?
<wpwrak>
BTLE has nothing to do with that
<DocScrutinizer05>
so how does a RTC?
<wpwrak>
BTLE needs accurate wakeups for protocol timing. if you cut power, it can't wakt up. so you would have to synchronize the power-controlling clock system with the wakeups required by the protocol stack.
<DocScrutinizer05>
huh???
<DocScrutinizer05>
and how don't you need exactly same for battery swap now?
<wpwrak>
that's all the details i know about the BTLE side. i don't know how long the pauses are and how precise the timing has to be. i would expect that it requires high accuracy, in the order of microseconds. this sort of protocol timing often does.
<DocScrutinizer05>
you completely lost me, I dunno what you're talking about
<DocScrutinizer05>
do you suggest to do battery swapping during a BTLE pause of 2ms?
<wpwrak>
battery swap is unrelated. RF goes down when you swap the battery. that's not a problem - it'll recover after powering back up. RF protocols are designed to tolerate losses and such.
<DocScrutinizer05>
SO WHAT's THE PROBLEM WITH A RTC INSTEAD RC THEN? and allow "battery swap" to take 10 days of power down
<wpwrak>
but an energy-efficient protocol can not afford sloppy timing. don't forget that sending and receiving (listening, where there is incoming data or not) are both almost equally expensive.
<DocScrutinizer05>
Oh My Gosh!
<DocScrutinizer05>
you just said RF is down during battery swap, and damn yep it better is
<wpwrak>
what i'm trying to get you to understand is that your "mostly off" operating scheme is not compatible with BTLE.
<wpwrak>
and we've already solved battery swap. no need to return to that.
<DocScrutinizer05>
WAAAAAAAAAH!!!!
<DocScrutinizer05>
so your anelok is an always-on RF device???
<wpwrak>
we have a simple and sufficient solution for that. now you're proposing a much more comoplex solution.
<DocScrutinizer05>
honestly, provide product requirement specs!
<wpwrak>
when BTLE is enabled, then the chip is "always on", yes
<DocScrutinizer05>
I don't want a security dongle that has RF enabled all the time. Heck I don't even want my phone to have BT enabled all the time
<DocScrutinizer05>
I'm out. I don't know the product requirements so any design effort is pointless
<wpwrak>
it's just a question of connectivity. being able to be reached doesn't mean that it has to answer. but it may alert the user of an incoming request. then the user can choose what to do with it.
<DocScrutinizer05>
aha
<DocScrutinizer05>
I'm out. I don't see how anelok "alerts user" when carried in pocket
<wpwrak>
it doesn't ;) but if it's on you desk, it will wake up and tell you what's going on
<DocScrutinizer05>
which point in product requirement specs is that?
<wpwrak>
so your workflow is: do whatever you're doing on your PC / mobile device. then pc / mob generates a request to anelok. anelok evaluates request and turns on. user then acks or denies request.
<DocScrutinizer05>
sorry I'm out. Not going to evaluate usecases on an adhoc basis
<wpwrak>
;-)
<DocScrutinizer05>
just a last comment on this one: why does anelok need to power up automatically and ask user to accept/deny? why can't user enable anelok *before* the request comes in?
<DocScrutinizer05>
and I don't expect an answer, I'm out
jwhitmore has quit [Ping timeout: 276 seconds]
<DocScrutinizer05>
actually an answer doesn't make sense without context of a comprehensive collection of usecases which need to get optimized then to have a canonical design solution
<wpwrak>
pre-authorizing requests is a possibility i wouldn't exclude. in this case anelok would not have to alert the user and could answer automatically. but that would be one of those "for future study" scenarios
<DocScrutinizer05>
sorry I'm out. making arbitrary usecases from design details that are derived from... dunno component properties doesn't really make sense
<wpwrak>
so for now i assume that users want to acknowledge each transaction explicitly. in any case, this doesn't affect things as far as BTLE is concerned.
<DocScrutinizer05>
it does affect whole device design, since you could simply switch on the device before you expect any request to come in
<DocScrutinizer05>
and now for real, I'm out. Thi sleads nowhere and we got 18°C in the big bluebox
sb0 has joined #qi-hardware
<DocScrutinizer05>
not only tinfoil hat anelok users will switch on RFKILL switch before they expect such request to happen, anyway. And they also will switch off RFKILL after they're done. So what's the problem with shutting down whole device with that "RFkill switch" and only keep a CMOS RTC running?
<DocScrutinizer05>
*massively* simplified more clean and more reliable design
<DocScrutinizer05>
afk
sandeepkr has quit [Ping timeout: 240 seconds]
xiangfu has joined #qi-hardware
xiangfu has quit [Remote host closed the connection]
<DocScrutinizer05>
just needs a diade from 3V3 Vdd to chip Vcc, and a resistor from battery to chip Vcc
<DocScrutinizer05>
diode*
<DocScrutinizer05>
assuming you don't run the rest of device in low power mode for significant fractions of time, and instead just switch it on when needed and then power it off again
<DocScrutinizer05>
or you already connect Vcc chip to system Vdd, and connect the battery more or less directly to chip's Vbat
<DocScrutinizer05>
(more or less directly) via a resistor that doesn't drop more than 0.2V@500nA
<DocScrutinizer05>
or even a diode, you told diodes can do that too
<DocScrutinizer05>
so your bom is: chip, diode, 220uF or even higher, depending on your batt swap time, plus the I2C stuff
<DocScrutinizer05>
plus you might want to dual-use the crystal, connecting SQW out to MCU's Xi32k
<DocScrutinizer05>
dunno what's your requirements for 32kHz on MCU without running a realtime clock there
<DocScrutinizer05>
when you don't need the 32kHz on MCU anymore, you even gain the 2 IO for I2C
<DocScrutinizer05>
and you don't need to worry at all (no hw powerfail, sw either) about 'closing shop' at powering down
<DocScrutinizer05>
waaaaay simpler and more solid design
<wpwrak>
still rather heavy just to keep time through a battery swap
<DocScrutinizer05>
it's not to keep time trough battery swap, it's to keep device off when not in use
<DocScrutinizer05>
thus voiding all your quiescent current worries you constantly discuss here
<wpwrak>
i don't think it can do that. or rather, it would need additional logic
<DocScrutinizer05>
yes, that logic is a hardware switch to power down whole anelok except RTC
<DocScrutinizer05>
switch on: everything up, incl LEDs and display, switch off and only RTC sucks battery
<DocScrutinizer05>
no shut down needed
<wpwrak>
to do it properly you'd need to be able to software-control the interrupt pin, so that you can use it as on/off switch
<DocScrutinizer05>
huh?
<wpwrak>
and forget the hardware switch. won't happen
<DocScrutinizer05>
you said you already have a hw switch
<DocScrutinizer05>
meh, I'm getting bored
<wpwrak>
for rfkill. not for power. it has mechanical buttons for control, though. so you could multi-use these. requiring some more components, of course
<DocScrutinizer05>
what's the difference between rfkill and poweroff of whole device?
<wpwrak>
rfkill only affects RF
<DocScrutinizer05>
the BT only disabled in sw when device powered on? well, I guess everybody can live with that
<wpwrak>
also, that rfkill switch is less convenient to operate than a button. besides, you'd need an auto-power-off then.
<DocScrutinizer05>
well, then use the button approach, I already explained how to implement that
<wpwrak>
you're dreaming up a device that's inconvenient to use, just to make it fit your circuit :)
<DocScrutinizer05>
simply power MCU via the pushbutton until it sets a GPIO to active-high to open a FET parallel to the pushbutton
<wpwrak>
yes, the buttons would work. you'd need to dual-feed them, etc., but all that is doable
<wpwrak>
i would't rely on an MCU-controlled FET to power down. what if the MCU goes erratic when under-powered ?
<DocScrutinizer05>
doesn't happen
<wpwrak>
what would be safe would be an i2c-controlled output of the RT
<wpwrak>
RTC even
<wpwrak>
but this chip doesn't have such a thing
<DocScrutinizer05>
if you're paranoic, use a AC-driven (pushpull GPIO) voltage doubler made from a capacitor and two diodes to operate the FETs gate
<DocScrutinizer05>
doubles as watchdog when CPU hangs
<wpwrak>
then the power-up sequence would be: user presses button, button forces boost EN high, mcu tells RTC via I2C to set its INT to "on", MCU retrieves time if it wants
<DocScrutinizer05>
yeah, why simple when we can do it digitally, but would work
<wpwrak>
for standby: set alarm at now + estimated cap hold time, reassign RTC INT to alarm (implicitly letting EN drop)
<DocScrutinizer05>
ohmy!!!!!
<DocScrutinizer05>
but yes, you could do that, unless you need 32kHz at MCU and don't want a second crystal for that
<wpwrak>
i don't think the MCU needs its own RTC clock in this case
<DocScrutinizer05>
since SQW and INT/ALARM are same pin for this particular chip
<wpwrak>
it could just run from its RC oscillator. burns a bit more power, but who cares
<DocScrutinizer05>
yeah, it does so only when device on
<wpwrak>
the cMCU (with USB) has its own crystal, so no problem there
<DocScrutinizer05>
anyway, I *really* should try to get some fresh air
<wpwrak>
yes ;-)
<DocScrutinizer05>
and I got a problem with "helmet hair" I need to solve ;-)
<wpwrak>
ah, ask for baldness cream at the pharmacy :)
<DocScrutinizer05>
("helmet hair" = terribly weird hairstyle after taking off helmet)
<wpwrak>
or get a "the beatles forever" t-shirt ;-)
<DocScrutinizer05>
yeah, that's my most likely approach
<DocScrutinizer05>
cut them
<DocScrutinizer05>
3mm
<wpwrak>
(helmet hair) ah, thought it was the helmet approach to cutting: place helmet (the old military kind), cut off protruding hair, remove helmet, done :)
<DocScrutinizer05>
nah, mine is already too short for that
<DocScrutinizer05>
14mm now
<wpwrak>
no special treatment needed then :)
<DocScrutinizer05>
after taking off helmet, I look like a punk with a very creative new variant of irokese hairstyle
<DocScrutinizer05>
either cut hair down to 3mm or get brisk hair creme
<wpwrak>
oh dear. the press seems to be going for the kill today. this front page alone speaks volumes: http://www.infobae.com/
<wpwrak>
this fellow was in charge of trains. among other nice things, he bought trains that were basically junk. probably making some handsome money on the side.
<DocScrutinizer05>
sounds like the usual pattern seen everywhere
<wpwrak>
the other nice things include partial responsibility for a train crash that killed some 50 people
<wpwrak>
we should use that as our standard for refurbs. would make it a lot easier to find more ;-)
<whitequark>
wtf
<DocScrutinizer05>
seems ALARM2 is working with chip Vcc as IRQ output
<DocScrutinizer05>
:-o
<DocScrutinizer05>
power-on states are yet to get inspected
<DocScrutinizer05>
seems SQW/INT works in 1Hz mode after power-up
<DocScrutinizer05>
so when you really want to control the main power switch from RTC INT you better make damn sure the MCU in itializes RTC during less than 500ms after main system power up
<DocScrutinizer05>
otherwise very funny effects will happen on battery insertion
<DocScrutinizer05>
(after full power down even for RTC)
<DocScrutinizer05>
I'd go for the GPIO controlled FET all days
<DocScrutinizer05>
of course you could connect the INT to the FETs gate as well, for ALARM wakeup - but only in parallel to a MCU GPIO
<DocScrutinizer05>
well then otoh what's the usecase for ALARM wakeup from system shutdown?
<DocScrutinizer05>
this datasheet is crap! :-< INTA string appears exactly once
<DocScrutinizer05>
oops there's more, for " INTA"
<DocScrutinizer05>
2 occurences, but no explanation which pin that is
<DocScrutinizer05>
anyway >> 8.11.9 Bit 1: Alarm 2 Flag (A2F) A logic 1 in the alarm 2 flag bit indicates that the time matched the alarm 2 registers. This flag can be used to generate an interrupt on SQW/INT depending on the status of the INTCN bit in the control register. If the INTCN bit is set to logic 0 and A2F is at logic 1 (and A2IE bit is also logic 1), the INTA pin goes low. If the INTCN bit is set to logic 1 and A2F is logic 1 (and A2IE bit
<DocScrutinizer05>
is also logic 1), the SQW/INT pin goes low. A2F is cleared when written to logic 0. This bit can only be written to logic 0. Attempting to write to logic 1 leaves the value unchanged.<<
<DocScrutinizer05>
you usually have to PAY to GET RID of such junk
<wpwrak>
(startup) time to first instruction is some 300 us. 1 second is something like eternity ;-)
<DocScrutinizer05>
yes, just saying
zcrc has joined #qi-hardware
zcrc has quit [Client Quit]
<DocScrutinizer05>
300us sounds sort of made up though. It takes longer for power to stabilize
<DocScrutinizer05>
possibly time for POR
<wpwrak>
(trains) in the comments, also some engineers from the field are commenting. pretty damning verdicts :)
<DocScrutinizer05>
where it's still the question when POR starts
<wpwrak>
300 us after reset is deasserted
<wpwrak>
so the MCU basically comes up "immediately"
<DocScrutinizer05>
so make sure your power-food plus reset-assertion plus 300us << 500ms
<DocScrutinizer05>
power-good even
<wpwrak>
the boost regulator should be up within something like 5 ms past minimum voltage
<wpwrak>
and there isn't much else between it and the battery
<wpwrak>
i.e., that 10 uF cap won't slow it for much :)
<DocScrutinizer05>
battery side? doesn't matter, it slows down RTC same way
<wpwrak>
the whole system would probably back asleep less than 10 ms after battery insertion :)
<DocScrutinizer05>
probably
<wpwrak>
well, if it skips over DFU :)
<DocScrutinizer05>
which it can doo without problems since on USB VBUS power I'd expect it to stay powered anyway
pcercuei has quit [Ping timeout: 246 seconds]
<DocScrutinizer05>
I also suggest it needs to hold power-button during connecting USB to even enter DFU mode
<DocScrutinizer05>
(or whichever button)
<DocScrutinizer05>
and first thing you want to do after power-up is to make sure system stays on and then (same time basically since it's same resource) check if powerfail bit in RTC got set
<DocScrutinizer05>
if that's the case you know you got wakened by 1Hz mode on RTC and you want to set time anyway before powering down again
<DocScrutinizer05>
otherwise you prolly got awajened by power pushbutton or ALARM
<DocScrutinizer05>
you easily can tell apart the both cases (button vs ALARM)
<DocScrutinizer05>
for ALARM the flag is set in RTC
<DocScrutinizer05>
(I still wonder what's the usecase for ALARM wakeup, but "never do a we_dont_need_that" design decision when it doesn't cost more than a few 0402 components and doesn't introduce unpredictable or known high risk anyway)
<DocScrutinizer05>
well, maybe you can check a 20ms for BTLE imbound signals every second, based on a 1Hz repetitive Alarm, if you really want that always-online property
<DocScrutinizer05>
so yes. a FET on RTC SQW/INT seems good design
<DocScrutinizer05>
plus a pushbutton to bridge that and force device on
<DocScrutinizer05>
to keep device on you set ALARM time to current time and simply don't clear the IRQ
<DocScrutinizer05>
to switch off you clear the IRQ
<DocScrutinizer05>
there are two alarms, you can use one for power switch and thus don't mess with alarm time setting of the other
<DocScrutinizer05>
if you want to do something for bat swap housekeeping then power up the device's 3V3 as soon as you notice battery voltage drop, so you can charge up the "bupbat" RTC capacitor a bit more than just to 1V2 of AAA cell
<DocScrutinizer05>
would make a difference of 0V3 vs 2V4 usable capacitor discharge
<DocScrutinizer05>
8 times backup time
<DocScrutinizer05>
would again need a decent prefail warning to work :-/
<DocScrutinizer05>
no use in powering up the device when the voltage on 10uF buffer capacitor starts to drop
<DocScrutinizer05>
HAH! you could use a voltage multiplier on SQW to charge the capacitor to 3V3 (or whatever Vmax) when you'd use the Vcc as IRQ output of ALARM (if that's even how stuff is supposed to work, the datasheet is pretty fuzzy and fsckdup there)
<DocScrutinizer05>
nah, doesn't work since your source (Vbattery 1V2) for driving the SQW electrically is also the destination (chip Vbat)
<DocScrutinizer05>
would nly work if AAA battery is connected to Vcc of chip, and that's not available in this scenario since we need it for INT instead of the SQW/INT pin
<DocScrutinizer05>
and even when it was, it seems the chip simply uses the supply with higher voltage for internal power
<DocScrutinizer05>
just make sure your capacitor can supply 500nA over 0.3V drop for as long as you need minimally to swap batery. For increased convenience user needs to power up the device before removing battery, which will result in almost 10 times longer timespan for batswap
<DocScrutinizer05>
NB the RTC chip was the first hit in DK for a timekeeping voltage <1V5
<wpwrak>
for INT to work, you need to power the whole chip. so that would be your D+C+chip scenario
<wpwrak>
the NXP ? yes
<DocScrutinizer05>
I didn't check if there are smarter or cheaper or easier chips
<wpwrak>
ah, i always sort by price :)
<wpwrak>
(alarm) you need that to wake up to recharge the cap :) that's how you keep it at a nice voltage
<DocScrutinizer05>
which cap you want to recharge?
<DocScrutinizer05>
the bupbat C? that one will be happy with voltages down to 0.9V
wildlander has quit [Read error: Connection reset by peer]
<wpwrak>
BTLE needs 16 us precision but in a 2 * 500 ppm window. so that translates to around +/-1 ms for a 1 s "poll" interval
<wpwrak>
those chips are about 3 orders of magnitude away from that
<DocScrutinizer05>
hmm, that's a topic for another day
<wpwrak>
the RTC cap. there is no bubat cap. bubat seems pointless, since it only keeps time but doesn't supply the interrupt
<DocScrutinizer05>
I don't think an inbound request for establishing a connection is in relation to BTLEs internal timing in any way
<wpwrak>
this is the timing for being ready to receive things
<DocScrutinizer05>
sure, but before you can do that you need to sync anyway
<DocScrutinizer05>
I don't suggest to go to sleep when a connection already got established
<wpwrak>
so you turn off for 999 -x ms, power up for x ms, then listen for 2 ms, then power down again.
<wpwrak>
being able to sleep is the whole point of BTLE :)
<DocScrutinizer05>
I don't want to discuss this now, it's a fringe case
<wpwrak>
it's the most standard use of BTLE ;-)
<DocScrutinizer05>
not when you don't have BTLE enabled
<DocScrutinizer05>
not when the device is off
<wpwrak>
BTLE is all about knowing when someone will talk to you, and not wasting energy on listening outside that interval
<DocScrutinizer05>
so what?
wildlander has joined #qi-hardware
* whitequark
stares at DocScrutinizer05
<wpwrak>
in fact, i'm a little disappointed about their 500 ppm thing. i would have made that much narrower :)
<DocScrutinizer05>
I really don't want to discuss BTLE specs now. If you want to use BTLE, you power up the device
<wpwrak>
500 ppm is just too tight for RC but way beyond what even the worst xtal can do
<DocScrutinizer05>
and after you did that, RTC is not relevant in the whole game anymore
<wpwrak>
yup. none of these chips seem to be adequate for BTLE, even if we assume the stack can use "external" timing (which so far i haven't been able to confirm)
<wpwrak>
so the only benefit is lower power consumption in standby
<wpwrak>
iff btle is off
<wpwrak>
(rfkill or just not enabled)
<DocScrutinizer05>
benefit of BTLE? yes exactly. I expect the sleep timing hgetting handled inside chip
<DocScrutinizer05>
the purpose of RTC is to decently power down whole anelok
<wpwrak>
benefit of the fancy RTC chip circuit vs. the simple RC
Luke-Jr has quit [Excess Flood]
<wpwrak>
i.e., both keep time, but one allows for lower-power standby
<DocScrutinizer05>
*sigh* we're back to square one now?
Luke-Jr has joined #qi-hardware
<DocScrutinizer05>
I'm out
<wpwrak>
;-)
<DocScrutinizer05>
please reread backscroll at around 10 to 20 lines before >>[2016-04-02 Sat 16:17:46] <DocScrutinizer05> *massively* simplified more clean and more reliable design<<
<DocScrutinizer05>
until >>[2016-04-02 Sat 18:44:54] <DocScrutinizer05> but yes, you could do that<<
<DocScrutinizer05>
and regarding your "keep the capacitor at charged state" you only do that to allow ALARM wakeup so you can do that. For nowmal operation of anelok you don't need repeated wakeups, you simply power up the device by pressing the powerbutton
<DocScrutinizer05>
and in shutdown mode the RTC runs from AAA cell
<DocScrutinizer05>
while when device powered up it runs from 3V3
<DocScrutinizer05>
and during battery swap you run RTC from a buffer capacitor charged to Vbat (>=1V2) or Vcc (3V3) whichever was present during a few seconds before battery removal
<DocScrutinizer05>
connect RTC's Vcc pin to 3V3 via a diode and to battery via a resistor or diode with 0V@500nA
<DocScrutinizer05>
I think I already said that
<DocScrutinizer05>
or you simply connect 3V3 to RTC Vcc and the R from battery to C-bupbat
<DocScrutinizer05>
BOM: RTC chip, crystal, buffer cap, diode from cap to 3V3 system Vdd, 2 GPIO and pullup R for I2C. On the savings side: R and C and one GPIO for the timekeeping-batswap hack, 2 GPIO and crystal for 32kHz. Further massive savings on sw side
<DocScrutinizer05>
for power you need one FET and a pushbutton but you save all the hassle with timekeeping, quiescent currents, writing to SD-card during system shutdown etc pp
<DocScrutinizer05>
so you spend one RTC chip, and one R, you save one GPIO and one C, and a lot of hassle with software and debugging and risk
<DocScrutinizer05>
and you can sanitize all that "always on" mess
<DocScrutinizer05>
and yes, you still could do your "switch it on every 10 seconds to charge capacitor so it could power up the device eventually" - but honestly you don't need that for all I can tell
wildlander has quit [Ping timeout: 244 seconds]
wildlander has joined #qi-hardware
<DocScrutinizer05>
without that, your device quiescent current is at a very easy to calculate max 500nA, for almost infinite time (prolly years) from one AAA
<DocScrutinizer05>
and after a year your still could swap battery and still have a pretty accurate time (the RTC chip allows xtal calibration in software)
<DocScrutinizer05>
no risk of aborted writes on SD which could easily physically destroy the card
<DocScrutinizer05>
no sw design hassle
<DocScrutinizer05>
no hw design hassle
<DocScrutinizer05>
if that doesn't sound convincing then I dunno what would
<DocScrutinizer05>
the RTC chip is a 50ct. If you wanna get fancy, add a 1000uF polyacene cap
<DocScrutinizer05>
or 15000uF or whatever you like
<DocScrutinizer05>
or the good ole (though large) XH414HG-IV01E 80mF at USD1.57@100
<DocScrutinizer05>
you should add a series resistor in the 3V3 diade line to limit charging current
<DocScrutinizer05>
diode
<DocScrutinizer05>
>> Also, by optimizing its materials, a 1 minute rapid charge stores approximately 90% of full capacity.<< http://media.digikey.com/pdf/Data Sheets/Seiko Instruments PDFs/CPH3225A_CP3225A.pdf
<DocScrutinizer05>
ESR 180 Ohm, so I guess this one doesn't really need any series R for charging limiting
<DocScrutinizer05>
won't hurt though
<DocScrutinizer05>
4.6uAh (3.3-1.8) means over 10h RTC without battery
<DocScrutinizer05>
I guess you can nuke R16 and C5 then
Luke-Jr has quit [Excess Flood]
<DocScrutinizer05>
the power button should pull high EN of boost converter
<DocScrutinizer05>
so you need a series resistor to EN and connect the pushbutton switch behind that one
<DocScrutinizer05>
from EN directly to bat+
<DocScrutinizer05>
watch out X2 and X4 don't mechanically interfere!
<DocScrutinizer05>
err x2 and x3, sorry
<DocScrutinizer05>
xtals can have very spooky long-distance interference when same frequency
<DocScrutinizer05>
I'd suggest to use only one xtal and share the clock, but we can't do that here, unless you find a RTC chip with one pin more for 32k_out
<DocScrutinizer05>
do you know how they calibrate xtal wrist watches? they use a ultrasonic body microphone and touch the glass with the tip
Luke-Jr has joined #qi-hardware
<DocScrutinizer05>
if you really don't like the "high cost" of 11mF supercap, you can use a 100uF for ~6 minutes (when charged to 3V3, 30s when charged to 1V2 from battery)
<DocScrutinizer05>
a 11mF however is way smaller than a 100uF ;-)
kilae has quit [Quit: ChatZilla 0.9.92 [Firefox 45.0.1/20160315153207]]
<DocScrutinizer05>
and I still dunno what are the expected "problems with supercaps"
<DocScrutinizer05>
maybe this quote can mitigate your worries? >> Its heat-resistant design allows for Pb-free reflowable SMT board attachment.<<