2016-04-02 00:17 hmm? 2016-04-02 01:38 sb0 has joined #qi-hardware 2016-04-02 02:46 luke-jr_ has quit [Ping timeout: 250 seconds] 2016-04-02 02:53 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. 2016-04-02 02:55 page 4 of http://downloads.qi-hardware.com/people/werner/anelok/tmp/anelok-20160401.pdf 2016-04-02 02:55 pull-up is R4, the transistor in question is Q1 2016-04-02 02:55 before i had an n-FET, but they can leak a lot more than a BJT 2016-04-02 02:56 (note that gate/base is uncritical in this case, since this is basically USB's VBUS) 2016-04-02 03:09 luke-jr_ has joined #qi-hardware 2016-04-02 03:33 DocScrutinizer05 has quit [Disconnected by services] 2016-04-02 03:33 DocScrutinizer05 has joined #qi-hardware 2016-04-02 03:58 luke-jr_ is now known as Luke-Jr 2016-04-02 04:52 sb0 has quit [Quit: Leaving] 2016-04-02 05:06 sandeepkr has quit [Ping timeout: 248 seconds] 2016-04-02 06:02 xiangfu has quit [Ping timeout: 276 seconds] 2016-04-02 06:04 xiangfu has joined #qi-hardware 2016-04-02 06:14 xiangfu has quit [Ping timeout: 264 seconds] 2016-04-02 06:15 xiangfu has joined #qi-hardware 2016-04-02 06:26 sb0 has joined #qi-hardware 2016-04-02 06:38 xiangfu has quit [Ping timeout: 250 seconds] 2016-04-02 06:57 sandeepkr has joined #qi-hardware 2016-04-02 09:44 jwhitmore has joined #qi-hardware 2016-04-02 09:51 wildlander has joined #qi-hardware 2016-04-02 11:06 sb0 has quit [Quit: Leaving] 2016-04-02 11:17 I'd use a cmos clock chip and a decent complete off 2016-04-02 11:34 kilae has joined #qi-hardware 2016-04-02 11:35 it's for disconnecting the battery when USB power is present ;) 2016-04-02 11:37 why do you even need that? 2016-04-02 11:40 xiangfu has joined #qi-hardware 2016-04-02 11:40 because i won't want to empty the battery when i have usb power ? 2016-04-02 11:48 but you empty the battery all the time when you don't have USB 2016-04-02 11:50 well, yes, if i don't have USB power, the battery is all i have :) 2016-04-02 11:51 so what's the use to save some 20 minutes out of a month? 2016-04-02 11:52 some people may keep their anelok connected most of the time 2016-04-02 11:52 some won't, of course 2016-04-02 11:53 the latter group will have to buy batteries more often :) 2016-04-02 11:54 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 2016-04-02 11:56 supercap problems, no thanks ;) 2016-04-02 11:56 besides, they're huge 2016-04-02 11:57 o.O 2016-04-02 11:57 and probably rather expensive, too 2016-04-02 11:58 do the math, then reject 2016-04-02 11:59 you need a goldcap for how much? 5 minutes? 2016-04-02 12:00 you prolly can use a tantal capacitor 2016-04-02 12:01 the problem isn't time but that supercaps don't start cheap. the cheapest is about USD 0.50 and is large 2016-04-02 12:01 besides, such a circuit would complicate time management quite a lot. especially for RF. 2016-04-02 12:02 total cost of ownership? $0.50 id say is cheep compared to buying a 2rd batt 2016-04-02 12:02 to replace the original dead one in the future 2016-04-02 12:03 huh? 2016-04-02 12:03 TCO = (cost(supercap) + cost(cmos clock)) * 3 + cost of supercap problems 2016-04-02 12:03 +1 for using a supercap 2016-04-02 12:03 ok 2016-04-02 12:03 what supercap problems? 2016-04-02 12:04 (idk nothing about the problems, i just like the idea, if its a pain, then fine) 2016-04-02 12:04 so that TCO is about ten batteries :) 2016-04-02 12:05 hmm ok 2016-04-02 12:05 i think i could still live with that 2016-04-02 12:06 http://www.digikey.com/product-search/en/integrated-circuits-ics/clock-timing-real-time-clocks/2556170 2016-04-02 12:06 xiangfu has quit [Ping timeout: 248 seconds] 2016-04-02 12:08 1,5V: http://www.digikey.com/product-detail/en/ams/AS1801-BTDT/AS1801-BTDTTR-ND/3095136 2016-04-02 12:10 500nA@1.5V 2016-04-02 12:10 beat that 2016-04-02 12:10 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 2016-04-02 12:14 you completely lost me 2016-04-02 12:15 besides, i may have to turn off the boost regulator also to prevent reverse charging. data sheet isn't entirely clear on that. 2016-04-02 12:15 when you can't control the sytemtime in parts of your system, then you are doomed anyway if you depend on that time, no? 2016-04-02 12:15 the part that controls it is also the one that depends on it. all i have to do is ensure that it's powered 2016-04-02 12:16 that's why I said "use a decent power button that triggers a `keep on` circuit" 2016-04-02 12:16 xiangfu has joined #qi-hardware 2016-04-02 12:17 sorry, I can't follow 2016-04-02 12:17 but that's something that's "always on" ... (BTLE) 2016-04-02 12:18 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. 2016-04-02 12:21 (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. 2016-04-02 12:21 so without prior solid R&D i wouldn't want to depend on such a scheme 2016-04-02 12:21 xiangfu has quit [Ping timeout: 246 seconds] 2016-04-02 12:23 xiangfu has joined #qi-hardware 2016-04-02 12:24 you already depend on such a scheme for battery swapping 2016-04-02 12:25 where your complete system loses time 2016-04-02 12:25 you need to set time in BTLE when iuser turns it on with switch, no? 2016-04-02 12:28 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 2016-04-02 12:29 heck, you even could use the RFKILL switch for powerswitch instead 2016-04-02 12:29 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. 2016-04-02 12:30 so which problem with a cmos clock instead? 2016-04-02 12:30 rfkill has a specific purpose 2016-04-02 12:30 $$$ and doesn't add anything useful 2016-04-02 12:30 huh?? 2016-04-02 12:30 do your math 2016-04-02 12:32 you're fighting 5 dozen problems that arise from trying to keep MCU always powered 2016-04-02 12:32 xiangfu has quit [Ping timeout: 244 seconds] 2016-04-02 12:32 as soon as RF enters the picture, i need to have power always anyway 2016-04-02 12:32 huh? why? 2016-04-02 12:33 because of timing. RF sleeps, then wakes up, briefly does its thing, then sleeps again. all this with precise timing. 2016-04-02 12:33 I guess I missed to read the product reqirement spec 2016-04-02 12:34 I wouldn't want to carry an always-on RF device with me 2016-04-02 12:34 you have rfkill to turn that off :) 2016-04-02 12:34 s/rfkill/power/ 2016-04-02 12:35 no. rfkill is specifically for the tin hat faction. kill RF, let you use anelok. 2016-04-02 12:35 ohmy 2016-04-02 12:36 yeah, evil anelok could be rooted so it enables RF in software when device powered on, even when code says it shouldn't 2016-04-02 12:37 exactly. and don't forget that, at least for some time, i don't control the firmware in the RF chip. 2016-04-02 12:37 much like we don't control the fw in the neo900 modem 2016-04-02 12:39 but that rfkill switch goes a bit beyond what we do there and is really impossible to bypass 2016-04-02 12:39 so? we don't have a hw power switch for Neo900 modem either 2016-04-02 12:39 yes, anelok doesn't have that vulnerability :) 2016-04-02 12:40 when you system in control gets hijacked, there's nothing you can do except shut it down completely 2016-04-02 12:40 ROTFL 2016-04-02 12:41 please provide a product requirements spec, with usecases 2016-04-02 12:42 (whn your system in control...) IF you even notice that rogue condition 2016-04-02 12:42 is the "secure core" gets compromised, you obviously have a problem 2016-04-02 12:42 there's no use in having a hw switch in your PCs internet cable, to mitigate virus attacks 2016-04-02 12:43 that rfkill also has some marketing dimension. it's an intuitively safe way to do it. 2016-04-02 12:44 some people airgap their computers 2016-04-02 12:44 and of course, that means no wireless either :) 2016-04-02 12:47 please provide a product requirements spec, with usecases 2016-04-02 12:47 anyway, no supercap, no clock chip, no I2C bus 2016-04-02 12:48 i don't have a finished document of that sort. but you can find most of the relevant information on the list 2016-04-02 12:48 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 2016-04-02 12:49 I'd do a proper I2C rather, every day 2016-04-02 12:50 to a 50ct RTC chip, with a 30ct cap as bupbat 2016-04-02 12:50 and shut the whole rest down when not iused 2016-04-02 12:50 more like 50 cts. or 80 cts if you want specs that say that you can actually solder it. 2016-04-02 12:54 you save that easily on other components that are not needed anymore 2016-04-02 12:55 well, almost. When you count in assembly and complexity and design, more than compensate it 2016-04-02 12:56 when user keeps anelok on USB 99% time, just don't 'switch it on' since it's always powered when on USB 2016-04-02 12:56 nuke your whole USB-shots-dwon-battery 2016-04-02 12:56 shuts-down even 2016-04-02 12:57 battery swap? nuke the whole nifty RC timekeeper stuff 2016-04-02 12:57 Luke-Jr has quit [Excess Flood] 2016-04-02 12:57 forget about quiescent currents completely since the device is 99.9% time off 2016-04-02 12:58 forget RFKILL since you shut down the complete device 2016-04-02 12:59 yeah you would need sw driven 'RFKILL' then for the 3 minutes you want to use anelok UI without BTLE 2016-04-02 12:59 I guess even tinfoil hats can cope with that 2016-04-02 13:00 Luke-Jr has joined #qi-hardware 2016-04-02 13:01 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 2016-04-02 13:01 you already got a RF-LED I've seen. Should be just good enough togethher with a sw-controlled power switch 2016-04-02 13:02 and you can be absolutely sure your device will keep accurate time and not eat more than 500nA from battery when powered down 2016-04-02 13:03 pretty simple to evaluate and verify from schematics, could prolly even get done algorithmically 2016-04-02 13:03 the rf led is for development. no really mean to be seen from the outside 2016-04-02 13:03 only the sMCU LED is intended to be visible 2016-04-02 13:04 hmmm, how about you make that a dual-color LED then? 2016-04-02 13:07 <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 2016-04-02 13:08 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 2016-04-02 13:08 err, there are 3-color LEDs ;-) 2016-04-02 13:09 aka RGB 2016-04-02 13:11 you certainly have a taste for expensive components :) 2016-04-02 13:11 decent design sometimes needs decent components 2016-04-02 13:13 i'd be more concerned about fringe features getting way too much weight :) 2016-04-02 13:14 lemme see how RGB vs. 3 LEDs compare, cost- and sourcing-wise ... 2016-04-02 13:15 leds leds, 13 cents, all three of them. sourcing obviously not an issue. now, rgb, 3.3V compatible, ... 2016-04-02 13:16 hehe, there's a red, UV, yellow-green tri-color LED ;-) 2016-04-02 13:17 http://www.digikey.com/product-search/en/optoelectronics/led-indication-discrete/524729?k=&pv37=780&FV=fff40008%2Cfff801b9&mnonly=0&newproducts=0&ColumnSort=0&page=1&quantity=0&ptm=0&fid=0&pageSize=25 2016-04-02 13:19 seems a RGB LED could be even cheaper than 3 monochrome LEDs 2016-04-02 13:20 for sure not significantly more expensive 2016-04-02 13:21 DK lists 604 components LED RGB 2016-04-02 13:21 that's an absolute fringe topic regarding CMOS RTC 2016-04-02 13:21 this one is only 21 cents. no too much more expensive. 2016-04-02 13:22 (blue has Vf = 3.1 V, so that's still 3.3 V compatible) 2016-04-02 13:22 http://www.digikey.com/product-detail/en/broadcom-limited/ASMB-MTB0-0A3A2/516-3279-1-ND/5695364 2016-04-02 13:22 yes, I picked blue for RF for a reason, it has best efficiency at 3.3V 2016-04-02 13:23 well, let's check the tolerance ... 2016-04-02 13:23 mmh. max 3.6 V. not so good. 2016-04-02 13:23 forget tolerance, those Vf 3V1 are for nominal If 2016-04-02 13:24 sure. around 10 mA or less it should be nice 2016-04-02 13:25 I suggest 1mA 2016-04-02 13:25 or 2 maybe if you go flashy 2016-04-02 13:26 If-nominal are 25mA 2016-04-02 13:26 so tolerance is negligible 2016-04-02 13:26 20 mA in this case 2016-04-02 13:27 o.O 2016-04-02 13:27 http://wstaw.org/m/2016/04/02/plasma-desktopKE2219.png 2016-04-02 13:28 yes, but that's abs max, not the test current for Vf 2016-04-02 13:28 aah k 2016-04-02 13:29 I guess the LED is rather 'boring', I'd rather discuss the RTC ;-) 2016-04-02 13:30 Vmin 0.9V, Vbat 1.2V, that's a 0.3V discharge at 500nA 2016-04-02 13:32 500nA * 240s / 0.3V 2016-04-02 13:32 ~500E-9 * 240 / 0.3 2016-04-02 13:32 pcercuei has joined #qi-hardware 2016-04-02 13:32 ~500*10**-9 * 240 / 0.3 2016-04-02 13:32 0.0004 2016-04-02 13:33 400uF 2016-04-02 13:34 no need to over-optimize leakage. the AAA will chemically leak after a few years anyway, so a few uA are fine. 2016-04-02 13:35 (400uF) for a 4 minutes. So much about "goldcap price and problems) 2016-04-02 13:36 s/)/"/ 2016-04-02 13:38 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 2016-04-02 13:39 aha 2016-04-02 13:39 well, you really don't see what I suggest 2016-04-02 13:40 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. 2016-04-02 13:40 how is a RTC incompatible where a systemclock with RC based guessing of power-down time isn't ? 2016-04-02 13:40 BTLE has nothing to do with that 2016-04-02 13:41 so how does a RTC? 2016-04-02 13:41 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. 2016-04-02 13:43 huh??? 2016-04-02 13:43 and how don't you need exactly same for battery swap now? 2016-04-02 13:43 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. 2016-04-02 13:44 you completely lost me, I dunno what you're talking about 2016-04-02 13:44 do you suggest to do battery swapping during a BTLE pause of 2ms? 2016-04-02 13:45 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. 2016-04-02 13:46 SO WHAT's THE PROBLEM WITH A RTC INSTEAD RC THEN? and allow "battery swap" to take 10 days of power down 2016-04-02 13:46 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. 2016-04-02 13:46 Oh My Gosh! 2016-04-02 13:47 you just said RF is down during battery swap, and damn yep it better is 2016-04-02 13:47 what i'm trying to get you to understand is that your "mostly off" operating scheme is not compatible with BTLE. 2016-04-02 13:48 and we've already solved battery swap. no need to return to that. 2016-04-02 13:48 WAAAAAAAAAH!!!! 2016-04-02 13:48 so your anelok is an always-on RF device??? 2016-04-02 13:48 we have a simple and sufficient solution for that. now you're proposing a much more comoplex solution. 2016-04-02 13:48 honestly, provide product requirement specs! 2016-04-02 13:49 when BTLE is enabled, then the chip is "always on", yes 2016-04-02 13:50 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 2016-04-02 13:52 I'm out. I don't know the product requirements so any design effort is pointless 2016-04-02 13:52 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. 2016-04-02 13:52 aha 2016-04-02 13:53 I'm out. I don't see how anelok "alerts user" when carried in pocket 2016-04-02 13:54 it doesn't ;) but if it's on you desk, it will wake up and tell you what's going on 2016-04-02 13:55 which point in product requirement specs is that? 2016-04-02 13:57 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. 2016-04-02 13:58 sorry I'm out. Not going to evaluate usecases on an adhoc basis 2016-04-02 13:58 ;-) 2016-04-02 13:59 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? 2016-04-02 13:59 and I don't expect an answer, I'm out 2016-04-02 14:00 jwhitmore has quit [Ping timeout: 276 seconds] 2016-04-02 14:01 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 2016-04-02 14:04 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 2016-04-02 14:06 sorry I'm out. making arbitrary usecases from design details that are derived from... dunno component properties doesn't really make sense 2016-04-02 14:06 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. 2016-04-02 14:07 it does affect whole device design, since you could simply switch on the device before you expect any request to come in 2016-04-02 14:08 and now for real, I'm out. Thi sleads nowhere and we got 18°C in the big bluebox 2016-04-02 14:12 sb0 has joined #qi-hardware 2016-04-02 14:16 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? 2016-04-02 14:17 *massively* simplified more clean and more reliable design 2016-04-02 14:18 afk 2016-04-02 14:57 sandeepkr has quit [Ping timeout: 240 seconds] 2016-04-02 15:54 xiangfu has joined #qi-hardware 2016-04-02 15:55 xiangfu has quit [Remote host closed the connection] 2016-04-02 16:06 sandeepkr has joined #qi-hardware 2016-04-02 16:11 http://media.digikey.com/pdf/Data Sheets/Austriamicrosystems PDFs/AS1801.pdf 2016-04-02 16:12 just needs a diade from 3V3 Vdd to chip Vcc, and a resistor from battery to chip Vcc 2016-04-02 16:12 diode* 2016-04-02 16:14 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 2016-04-02 16:18 or you already connect Vcc chip to system Vdd, and connect the battery more or less directly to chip's Vbat 2016-04-02 16:19 (more or less directly) via a resistor that doesn't drop more than 0.2V@500nA 2016-04-02 16:20 or even a diode, you told diodes can do that too 2016-04-02 16:22 so your bom is: chip, diode, 220uF or even higher, depending on your batt swap time, plus the I2C stuff 2016-04-02 16:23 plus you might want to dual-use the crystal, connecting SQW out to MCU's Xi32k 2016-04-02 16:25 dunno what's your requirements for 32kHz on MCU without running a realtime clock there 2016-04-02 16:26 when you don't need the 32kHz on MCU anymore, you even gain the 2 IO for I2C 2016-04-02 16:27 and you don't need to worry at all (no hw powerfail, sw either) about 'closing shop' at powering down 2016-04-02 16:28 waaaaay simpler and more solid design 2016-04-02 16:30 still rather heavy just to keep time through a battery swap 2016-04-02 16:31 it's not to keep time trough battery swap, it's to keep device off when not in use 2016-04-02 16:31 thus voiding all your quiescent current worries you constantly discuss here 2016-04-02 16:31 i don't think it can do that. or rather, it would need additional logic 2016-04-02 16:33 yes, that logic is a hardware switch to power down whole anelok except RTC 2016-04-02 16:34 switch on: everything up, incl LEDs and display, switch off and only RTC sucks battery 2016-04-02 16:34 no shut down needed 2016-04-02 16:34 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 2016-04-02 16:34 huh? 2016-04-02 16:34 and forget the hardware switch. won't happen 2016-04-02 16:35 you said you already have a hw switch 2016-04-02 16:35 meh, I'm getting bored 2016-04-02 16:36 for rfkill. not for power. it has mechanical buttons for control, though. so you could multi-use these. requiring some more components, of course 2016-04-02 16:36 what's the difference between rfkill and poweroff of whole device? 2016-04-02 16:37 rfkill only affects RF 2016-04-02 16:37 the BT only disabled in sw when device powered on? well, I guess everybody can live with that 2016-04-02 16:37 also, that rfkill switch is less convenient to operate than a button. besides, you'd need an auto-power-off then. 2016-04-02 16:38 well, then use the button approach, I already explained how to implement that 2016-04-02 16:38 you're dreaming up a device that's inconvenient to use, just to make it fit your circuit :) 2016-04-02 16:38 simply power MCU via the pushbutton until it sets a GPIO to active-high to open a FET parallel to the pushbutton 2016-04-02 16:39 yes, the buttons would work. you'd need to dual-feed them, etc., but all that is doable 2016-04-02 16:40 i would't rely on an MCU-controlled FET to power down. what if the MCU goes erratic when under-powered ? 2016-04-02 16:40 doesn't happen 2016-04-02 16:40 what would be safe would be an i2c-controlled output of the RT 2016-04-02 16:40 RTC even 2016-04-02 16:40 but this chip doesn't have such a thing 2016-04-02 16:41 if you're paranoic, use a AC-driven (pushpull GPIO) voltage doubler made from a capacitor and two diodes to operate the FETs gate 2016-04-02 16:42 doubles as watchdog when CPU hangs 2016-04-02 16:42 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 2016-04-02 16:43 yeah, why simple when we can do it digitally, but would work 2016-04-02 16:43 for standby: set alarm at now + estimated cap hold time, reassign RTC INT to alarm (implicitly letting EN drop) 2016-04-02 16:43 ohmy!!!!! 2016-04-02 16:44 but yes, you could do that, unless you need 32kHz at MCU and don't want a second crystal for that 2016-04-02 16:45 i don't think the MCU needs its own RTC clock in this case 2016-04-02 16:45 since SQW and INT/ALARM are same pin for this particular chip 2016-04-02 16:46 it could just run from its RC oscillator. burns a bit more power, but who cares 2016-04-02 16:46 yeah, it does so only when device on 2016-04-02 16:47 the cMCU (with USB) has its own crystal, so no problem there 2016-04-02 16:47 anyway, I *really* should try to get some fresh air 2016-04-02 16:47 yes ;-) 2016-04-02 16:48 and I got a problem with "helmet hair" I need to solve ;-) 2016-04-02 16:48 ah, ask for baldness cream at the pharmacy :) 2016-04-02 16:49 ("helmet hair" = terribly weird hairstyle after taking off helmet) 2016-04-02 16:49 or get a "the beatles forever" t-shirt ;-) 2016-04-02 16:49 yeah, that's my most likely approach 2016-04-02 16:49 cut them 2016-04-02 16:49 3mm 2016-04-02 16:50 (helmet hair) ah, thought it was the helmet approach to cutting: place helmet (the old military kind), cut off protruding hair, remove helmet, done :) 2016-04-02 16:50 nah, mine is already too short for that 2016-04-02 16:51 14mm now 2016-04-02 16:51 no special treatment needed then :) 2016-04-02 16:51 after taking off helmet, I look like a punk with a very creative new variant of irokese hairstyle 2016-04-02 16:52 either cut hair down to 3mm or get brisk hair creme 2016-04-02 16:53 oh dear. the press seems to be going for the kill today. this front page alone speaks volumes: http://www.infobae.com/ 2016-04-02 16:53 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. 2016-04-02 16:54 sounds like the usual pattern seen everywhere 2016-04-02 16:54 the other nice things include partial responsibility for a train crash that killed some 50 people 2016-04-02 16:54 yeah, he overdid it a bit, though 2016-04-02 16:55 a mean, look a the pics of junk he bought: http://www.infobae.com/2016/04/02/1801434-194-fotos-los-trenes-inservibles-comprados-ricardo-jaime 2016-04-02 16:56 we should use that as our standard for refurbs. would make it a lot easier to find more ;-) 2016-04-02 17:03 wtf 2016-04-02 17:10 seems ALARM2 is working with chip Vcc as IRQ output 2016-04-02 17:11 :-o 2016-04-02 17:12 power-on states are yet to get inspected 2016-04-02 17:12 seems SQW/INT works in 1Hz mode after power-up 2016-04-02 17:13 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 2016-04-02 17:14 otherwise very funny effects will happen on battery insertion 2016-04-02 17:15 (after full power down even for RTC) 2016-04-02 17:16 I'd go for the GPIO controlled FET all days 2016-04-02 17:18 of course you could connect the INT to the FETs gate as well, for ALARM wakeup - but only in parallel to a MCU GPIO 2016-04-02 17:20 well then otoh what's the usecase for ALARM wakeup from system shutdown? 2016-04-02 17:26 this datasheet is crap! :-< INTA string appears exactly once 2016-04-02 17:27 oops there's more, for " INTA" 2016-04-02 17:28 2 occurences, but no explanation which pin that is 2016-04-02 17:29 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 2016-04-02 17:29 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.<< 2016-04-02 17:38 http://cdn01.ib.infobae.com/adjuntos/162/imagenes/014/517/0014517260.jpg?0000-00-00-00-00-00 is really beyond any joke 2016-04-02 17:39 you usually have to PAY to GET RID of such junk 2016-04-02 17:39 (startup) time to first instruction is some 300 us. 1 second is something like eternity ;-) 2016-04-02 17:40 yes, just saying 2016-04-02 17:40 zcrc has joined #qi-hardware 2016-04-02 17:40 zcrc has quit [Client Quit] 2016-04-02 17:40 300us sounds sort of made up though. It takes longer for power to stabilize 2016-04-02 17:41 possibly time for POR 2016-04-02 17:41 (trains) in the comments, also some engineers from the field are commenting. pretty damning verdicts :) 2016-04-02 17:41 where it's still the question when POR starts 2016-04-02 17:41 300 us after reset is deasserted 2016-04-02 17:42 so the MCU basically comes up "immediately" 2016-04-02 17:42 so make sure your power-food plus reset-assertion plus 300us << 500ms 2016-04-02 17:43 power-good even 2016-04-02 17:44 the boost regulator should be up within something like 5 ms past minimum voltage 2016-04-02 17:44 and there isn't much else between it and the battery 2016-04-02 17:45 i.e., that 10 uF cap won't slow it for much :) 2016-04-02 17:45 battery side? doesn't matter, it slows down RTC same way 2016-04-02 17:45 the whole system would probably back asleep less than 10 ms after battery insertion :) 2016-04-02 17:46 probably 2016-04-02 17:46 well, if it skips over DFU :) 2016-04-02 17:47 which it can doo without problems since on USB VBUS power I'd expect it to stay powered anyway 2016-04-02 17:47 pcercuei has quit [Ping timeout: 246 seconds] 2016-04-02 17:49 I also suggest it needs to hold power-button during connecting USB to even enter DFU mode 2016-04-02 17:49 (or whichever button) 2016-04-02 17:51 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 2016-04-02 17:52 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 2016-04-02 17:53 otherwise you prolly got awajened by power pushbutton or ALARM 2016-04-02 17:53 you easily can tell apart the both cases (button vs ALARM) 2016-04-02 17:54 for ALARM the flag is set in RTC 2016-04-02 17:56 (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) 2016-04-02 17:58 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 2016-04-02 18:00 so yes. a FET on RTC SQW/INT seems good design 2016-04-02 18:00 plus a pushbutton to bridge that and force device on 2016-04-02 18:02 to keep device on you set ALARM time to current time and simply don't clear the IRQ 2016-04-02 18:02 to switch off you clear the IRQ 2016-04-02 18:04 there are two alarms, you can use one for power switch and thus don't mess with alarm time setting of the other 2016-04-02 18:09 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 2016-04-02 18:10 would make a difference of 0V3 vs 2V4 usable capacitor discharge 2016-04-02 18:10 8 times backup time 2016-04-02 18:12 would again need a decent prefail warning to work :-/ 2016-04-02 18:12 no use in powering up the device when the voltage on 10uF buffer capacitor starts to drop 2016-04-02 18:18 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) 2016-04-02 18:21 nah, doesn't work since your source (Vbattery 1V2) for driving the SQW electrically is also the destination (chip Vbat) 2016-04-02 18:22 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 2016-04-02 18:23 and even when it was, it seems the chip simply uses the supply with higher voltage for internal power 2016-04-02 18:25 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 2016-04-02 18:27 NB the RTC chip was the first hit in DK for a timekeeping voltage <1V5 2016-04-02 18:27 for INT to work, you need to power the whole chip. so that would be your D+C+chip scenario 2016-04-02 18:28 the NXP ? yes 2016-04-02 18:28 I didn't check if there are smarter or cheaper or easier chips 2016-04-02 18:28 ah, i always sort by price :) 2016-04-02 18:28 (alarm) you need that to wake up to recharge the cap :) that's how you keep it at a nice voltage 2016-04-02 18:29 which cap you want to recharge? 2016-04-02 18:29 the bupbat C? that one will be happy with voltages down to 0.9V 2016-04-02 18:30 wildlander has quit [Read error: Connection reset by peer] 2016-04-02 18:30 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 2016-04-02 18:30 those chips are about 3 orders of magnitude away from that 2016-04-02 18:30 hmm, that's a topic for another day 2016-04-02 18:31 the RTC cap. there is no bubat cap. bubat seems pointless, since it only keeps time but doesn't supply the interrupt 2016-04-02 18:31 I don't think an inbound request for establishing a connection is in relation to BTLEs internal timing in any way 2016-04-02 18:32 this is the timing for being ready to receive things 2016-04-02 18:32 sure, but before you can do that you need to sync anyway 2016-04-02 18:33 I don't suggest to go to sleep when a connection already got established 2016-04-02 18:33 so you turn off for 999 -x ms, power up for x ms, then listen for 2 ms, then power down again. 2016-04-02 18:33 being able to sleep is the whole point of BTLE :) 2016-04-02 18:33 I don't want to discuss this now, it's a fringe case 2016-04-02 18:34 it's the most standard use of BTLE ;-) 2016-04-02 18:34 not when you don't have BTLE enabled 2016-04-02 18:34 not when the device is off 2016-04-02 18:34 BTLE is all about knowing when someone will talk to you, and not wasting energy on listening outside that interval 2016-04-02 18:34 so what? 2016-04-02 18:34 wildlander has joined #qi-hardware 2016-04-02 18:35 * whitequark stares at DocScrutinizer05 2016-04-02 18:35 in fact, i'm a little disappointed about their 500 ppm thing. i would have made that much narrower :) 2016-04-02 18:35 I really don't want to discuss BTLE specs now. If you want to use BTLE, you power up the device 2016-04-02 18:36 500 ppm is just too tight for RC but way beyond what even the worst xtal can do 2016-04-02 18:36 and after you did that, RTC is not relevant in the whole game anymore 2016-04-02 18:37 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) 2016-04-02 18:38 so the only benefit is lower power consumption in standby 2016-04-02 18:38 iff btle is off 2016-04-02 18:38 (rfkill or just not enabled) 2016-04-02 18:38 benefit of BTLE? yes exactly. I expect the sleep timing hgetting handled inside chip 2016-04-02 18:39 the purpose of RTC is to decently power down whole anelok 2016-04-02 18:39 benefit of the fancy RTC chip circuit vs. the simple RC 2016-04-02 18:39 Luke-Jr has quit [Excess Flood] 2016-04-02 18:40 i.e., both keep time, but one allows for lower-power standby 2016-04-02 18:40 *sigh* we're back to square one now? 2016-04-02 18:40 Luke-Jr has joined #qi-hardware 2016-04-02 18:40 I'm out 2016-04-02 18:40 ;-) 2016-04-02 18:45 please reread backscroll at around 10 to 20 lines before >>[2016-04-02 Sat 16:17:46] *massively* simplified more clean and more reliable design<< 2016-04-02 18:47 until >>[2016-04-02 Sat 18:44:54] but yes, you could do that<< 2016-04-02 18:50 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 2016-04-02 18:51 and in shutdown mode the RTC runs from AAA cell 2016-04-02 18:51 while when device powered up it runs from 3V3 2016-04-02 18:55 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 2016-04-02 18:57 connect RTC's Vcc pin to 3V3 via a diode and to battery via a resistor or diode with 0V@500nA 2016-04-02 18:57 I think I already said that 2016-04-02 18:59 or you simply connect 3V3 to RTC Vcc and the R from battery to C-bupbat 2016-04-02 19:00 aka RTC Vbat 2016-04-02 19:10 http://wstaw.org/m/2016/04/02/plasma-desktopeo2219.png http://wstaw.org/m/2016/04/02/plasma-desktopoA2219.png 2016-04-02 19:14 you *probably* could even connect RTC Vbat to a buffer cap and to 3V3 via a diode, and connect RTC Vcc to battery directly 2016-04-02 19:15 if everything in the datasheet is correct, this is the best way to integrate the RTC 2016-04-02 19:17 http://wstaw.org/m/2016/04/02/plasma-desktopqH2219.png 2016-04-02 19:19 together with above quoted http://wstaw.org/m/2016/04/02/plasma-desktopeo2219.png 2016-04-02 19:23 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 2016-04-02 19:25 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 2016-04-02 19:28 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 2016-04-02 19:29 and you can sanitize all that "always on" mess 2016-04-02 19:34 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 2016-04-02 19:35 wildlander has quit [Ping timeout: 244 seconds] 2016-04-02 19:36 wildlander has joined #qi-hardware 2016-04-02 19:37 without that, your device quiescent current is at a very easy to calculate max 500nA, for almost infinite time (prolly years) from one AAA 2016-04-02 19:38 and after a year your still could swap battery and still have a pretty accurate time (the RTC chip allows xtal calibration in software) 2016-04-02 19:39 no risk of aborted writes on SD which could easily physically destroy the card 2016-04-02 19:39 no sw design hassle 2016-04-02 19:40 no hw design hassle 2016-04-02 19:46