2016-03-25 01:52 archang has joined #qi-hardware
2016-03-25 02:01 archang has quit [Ping timeout: 276 seconds]
2016-03-25 02:17 archang has joined #qi-hardware
2016-03-25 02:56 fengling has quit [Ping timeout: 240 seconds]
2016-03-25 02:59 archang has quit [Ping timeout: 244 seconds]
2016-03-25 03:05 archang has joined #qi-hardware
2016-03-25 03:06 fengling has joined #qi-hardware
2016-03-25 04:00 sandeepkr has joined #qi-hardware
2016-03-25 04:22 DocScrutinizer05 has quit [Disconnected by services]
2016-03-25 04:22 DocScrutinizer05 has joined #qi-hardware
2016-03-25 05:29 GeorgeHahn has joined #qi-hardware
2016-03-25 05:50 <wpwrak> (write to storage) i have a low voltage warning (interrupt), so if the rail doesn't drop at an insane speed (i.e., shorted), i should have a fair amount of time to react. fair at least with respect to the n * 65 us it takes to write n longwords to flash
2016-03-25 05:53 <wpwrak> (fancy mechanics) naw, i try to keep things simple. no bespoke parts if not absolutely unavoidable. i'm not apple or samsung ;-)
2016-03-25 05:55 <wpwrak> Td and Tc are the times during which the MCU leaves the circuit alone, e.g., to take a nap. they're basically the predicted intervals for going from the last Vh to Vmin, or from the latest Vl to Vtop, respectively
2016-03-25 05:58 <wpwrak> (one-time calibration) i suspect temperature effects would screws this up. in any case, i need to do the charge/discharge cycling if i don't want to have a constant leakage of 3.3 V / R3, so i may as well calibrate while at it
2016-03-25 05:59 <wpwrak> (ADC on battery) i have that. ron already suggested it a few days ago ;-)
2016-03-25 05:59 <wpwrak> (VDD by booster) yes
2016-03-25 06:03 <wpwrak> (low predictability of rail collapse) i kinda wonder if this could be helped :) in any case, it may be worth adding a DNP resistor, for experiments
2016-03-25 06:06 arossdotme-planb has quit [Ping timeout: 240 seconds]
2016-03-25 06:07 arossdotme-planb has joined #qi-hardware
2016-03-25 06:08 <kristianpaul> wpwrak: http://www.bristol-seds.co.uk/pico-tracker/
2016-03-25 06:15 <wpwrak> needs a car-mounted variant, then you can go breaking bad ;-)
2016-03-25 06:23 <wpwrak> DocScrutinizer05: ah, one potential efficiency improvement: pFET left of R2, with the gate on Vcc, then go directly to GND (so we no longer have CHARGE or R2). if the rail collapses reasonably quickly below Vc1 - Vgs(th), then this would provide an energy-efficient way of activating the pull-down.
2016-03-25 06:24 fengling has quit [Ping timeout: 240 seconds]
2016-03-25 06:24 <wpwrak> this would be more robust with respect to unpredictably decaying rails because the threshold would be fairly high, where the rail should still collapse quickly
2016-03-25 06:25 <wpwrak> like to C1 to VDD approach, discharging would only be needed for calibration
2016-03-25 06:26 fengling has joined #qi-hardware
2016-03-25 06:26 GeorgeHahn has quit [Read error: Connection reset by peer]
2016-03-25 06:56 fengling has quit [Ping timeout: 240 seconds]
2016-03-25 07:02 <wpwrak> DocScrutinizer05: is http://maemo.cloud-7.de/share-service/DSCF1916.JPG a long-term stable URL ? i.e., can i reference it in a post to qi-hw ?
2016-03-25 07:49 fengling has joined #qi-hardware
2016-03-25 07:53 fengling has quit [Ping timeout: 240 seconds]
2016-03-25 08:29 <wpwrak> DocScrutinizer05: now all three variants: the original, the fragile one that relies on Vcc's predictability, and the more robust one with FET: http://downloads.qi-hardware.com/people/werner/anelok/tmp/time-backup-draft-20160325.pdf
2016-03-25 08:34 fengling has joined #qi-hardware
2016-03-25 09:40 uwe_mobile has quit [Ping timeout: 240 seconds]
2016-03-25 09:40 uwe_mobile has joined #qi-hardware
2016-03-25 10:23 fengling has quit [Quit: WeeChat 1.4]
2016-03-25 10:27 <DocScrutinizer05> yes, the link is medium-term stable
2016-03-25 10:28 <DocScrutinizer05> please use http://joerg.cloud-7.de/share-service/DSCF1916.JPG
2016-03-25 10:29 <DocScrutinizer05> or copy the photo to wherever you like
2016-03-25 11:14 sandeepkr has quit [Ping timeout: 244 seconds]
2016-03-25 12:44 doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
2016-03-25 13:01 sandeepkr has joined #qi-hardware
2016-03-25 13:55 archang has quit [Ping timeout: 248 seconds]
2016-03-25 13:58 <DocScrutinizer05> http://downloads.qi-hardware.com/people/werner/anelok/tmp/time-backup-draft-20160325.pdf page 3: I wonder how wide the operational range of Vc1
2016-03-25 13:58 doomlord has joined #qi-hardware
2016-03-25 13:58 <DocScrutinizer05> you need to consider it drops over time, so eventually the FET will close due to insufficient Vgs
2016-03-25 14:01 <DocScrutinizer05> unless of course you use a depletion type FET
2016-03-25 14:01 <DocScrutinizer05> aka "normally conducting"
2016-03-25 14:05 <wpwrak> ah, i'm thinking of a MOSFET. and yes, it would reduce the valid range to Vc1 >= Vgs(th) + Vcc_residual. so probably chops it in half or such. still, not a big deal.
2016-03-25 14:06 <wpwrak>  s/MOSFET/enhancement mode MOSFET/
2016-03-25 14:07 <wpwrak> lemme see what characteristics the depletion critters have.  never used them.
2016-03-25 14:11 <DocScrutinizer05> well, the most relevant property of depletion type in this context is: with Vgs=0 (or floating) it's in conducting mode
2016-03-25 14:12 <wpwrak> p-channel depletion doesn't even seem to exist in the wild. good. one choice less to worry about ;-)
2016-03-25 14:13 <DocScrutinizer05> depletion types are significantly less comman than enrichment types
2016-03-25 14:13 <wpwrak> looking at n-channel, it seems to be pretty hard to get them to actually close
2016-03-25 14:13 <wpwrak> yes. i found this intro: http://www.aldinc.com/pdf/IntroDepletionModeMOSFET.pdf
2016-03-25 14:14 <wpwrak> also, a digi-key search shows no rich pickings :)
2016-03-25 14:15 <wpwrak> naw, but i think it should work okay with a regular p-FET
2016-03-25 14:16 <DocScrutinizer05> not convinced
2016-03-25 14:27 <wpwrak> let's see ... yeah, need to increase C1 a little
2016-03-25 14:27 <DocScrutinizer05> yeah, like factor 10 or 50
2016-03-25 14:27 <wpwrak> if we cut off at, say, 1.5 V, then ... 33 uF would give us 86 s
2016-03-25 14:28 <DocScrutinizer05> Vth is higher than 1.5V
2016-03-25 14:28 <wpwrak> there are plenty of FETs with Vgs(th) < 1.5 V
2016-03-25 14:28 <DocScrutinizer05> and you discharge a 3V to GND via R, while the discharge stops at 2V (Vgs_th)
2016-03-25 14:29 <DocScrutinizer05> honestly what's wrong with a depletion type?
2016-03-25 14:30 <DocScrutinizer05> it closed when VDD good, and opens when VDD ~zero
2016-03-25 14:30 <wpwrak> there is one with Vgs(th) = 1.2 V for 1.5 uA: http://www.digikey.com/product-detail/en/infineon-technologies/BSS223PWH6327XTSA1/BSS223PWH6327XTSA1CT-ND/5410003
2016-03-25 14:31 <wpwrak> and very low leakage, too
2016-03-25 14:37 <wpwrak> (depletion) it seems that we'd still need a p-channel FET, for which the depletion type don't appear to exist in the wild.
2016-03-25 14:41 <DocScrutinizer05> what is the problem we're trying to solve, to start with?
2016-03-25 14:42 doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
2016-03-25 14:42 <DocScrutinizer05> I think we're overengineering this
2016-03-25 14:50 <wpwrak> measuring power-off-time
2016-03-25 14:51 <wpwrak> ideally with something around 1% accuracy
2016-03-25 14:52 <DocScrutinizer05> no, I mean why do we need the FET?
2016-03-25 14:55 <wpwrak> to cut the discharging while powered on. even a few uA are not nice at this point.
2016-03-25 14:55 <DocScrutinizer05> what's the problems we expect to find when in p.3 we make R1:DNP, R2: 3M3
2016-03-25 14:56 <wpwrak> and then remove Q3, too ?
2016-03-25 14:56 <wpwrak> err, Q1
2016-03-25 14:56 <DocScrutinizer05> Sure! during CPU up we charge via GPIO
2016-03-25 14:57 <DocScrutinizer05> ooops, P.2 I meant
2016-03-25 14:57 <wpwrak> ah. lemme see ...
2016-03-25 14:58 <wpwrak> the GPIO is most likely closed when powered down. so it wouldn't discharge C1
2016-03-25 14:58 <DocScrutinizer05> when CPU down, VDD is low and discharge worky via clamp diode in chip to VDD
2016-03-25 14:58 <DocScrutinizer05> works*
2016-03-25 14:59 <wpwrak> there's no such clamp in the MCU. we could add one outside, though.
2016-03-25 14:59 <DocScrutinizer05> yep
2016-03-25 14:59 <wpwrak> that would be similar to the FET. maybe better, though, due to Vf < Vgs(th)
2016-03-25 14:59 <DocScrutinizer05> prolly much better circuit characteristics than the FET solution
2016-03-25 15:00 <DocScrutinizer05> inaccuracy mostly depends on VDD drop time which isn't meant to be slower than max 2 seconds
2016-03-25 15:00 <wpwrak> ah, and a large R2 may amplify leakage current a bit too much. that's why i try to keep this low. already 680 kOhm are uncomfortable.
2016-03-25 15:00 <DocScrutinizer05> hmm?
2016-03-25 15:02 <wpwrak> leakage current of ADC GPIO. if it's, say, 100 nA, we'd have an error of up to 10% of the signal we're trying to measure. an error that itself may be tricky to compensate
2016-03-25 15:02 <DocScrutinizer05> prolly not
2016-03-25 15:02 <DocScrutinizer05> should be pretty easy to compensate for
2016-03-25 15:02 <DocScrutinizer05> actually, calibrate
2016-03-25 15:04 <wpwrak> (diode) actually, would this be better than the existing page 2 ? you still have the problem that the pull-down is to Vcc, which may become unpredictable near the bottom
2016-03-25 15:04 <wpwrak> so all the diode would do is cut out the top of the drop, which is the safest part
2016-03-25 15:04 <DocScrutinizer05> btw you have a very precise way to determine the true voltage of C, by measuring the discharge slew rate
2016-03-25 15:05 <DocScrutinizer05> sorry you completely lost me
2016-03-25 15:06 <wpwrak> let me rephrase it: how would your suggested modification of page 2 improve over what page 2 already does ?
2016-03-25 15:07 <DocScrutinizer05> it discharges during VDD slowly dropping to the point where CPU ceases to work
2016-03-25 15:07 <DocScrutinizer05> and it doesn't start charging on battery insertion while CPU still initializes
2016-03-25 15:08 <DocScrutinizer05> the latter is significant
2016-03-25 15:09 <wpwrak> initialization time should be very predictable
2016-03-25 15:09 <DocScrutinizer05> since you have C pretty much discharged so voltage over R1 and thus charge rate is very high compared to the interesting residual charge
2016-03-25 15:09 <wpwrak> but yes, there could be issues with contact bounce, as the user fumbles the battery into place
2016-03-25 15:10 <DocScrutinizer05> yes, for example
2016-03-25 15:11 <DocScrutinizer05> I'm pretty sure the simpler solution is the better (higher quality) one here
2016-03-25 15:11 <DocScrutinizer05> simply test it and see if it works
2016-03-25 15:12 <DocScrutinizer05> instead of introducing new problems while trying to solve percieved flaws of a already complex solution
2016-03-25 15:12 <wpwrak> i don't get "it discharges during VDD slowly dropping to the point where CPU ceases to work", though. in any case, we become aware of problems only on the low-voltage interrupt. that may be a relatively long or a very short time after battery removal. typically i'd expect a few seconds, given that the system will probably be asleep
2016-03-25 15:13 <DocScrutinizer05> you need an interrupt as soon as battery gets removed
2016-03-25 15:14 <DocScrutinizer05> you can't make the CPU "call 911 when you lose conciousness"
2016-03-25 15:14 doomlord has joined #qi-hardware
2016-03-25 15:15 <wpwrak> the MCU has two thresholds: a low-voltage threshold and a reset/brown-out threshold.
2016-03-25 15:15 doomlord has quit [Client Quit]
2016-03-25 15:16 <DocScrutinizer05> pretty simple method: couple a GPIO/IRQ (falling edge) CPU input to Vbatt via a 1nF, and have a pullup R of maybe 100k from GPIO/IRQ to VDD
2016-03-25 15:17 <DocScrutinizer05> well, maybe you need a R voltage devicer to adjust the threshold/bias
2016-03-25 15:17 <wpwrak> you mean pull-down ?
2016-03-25 15:17 <DocScrutinizer05> no, I mean pullup
2016-03-25 15:17 <wpwrak> ah, i see
2016-03-25 15:17 <wpwrak> you use the battery to pull down :)
2016-03-25 15:17 <DocScrutinizer05> yes
2016-03-25 15:17 <DocScrutinizer05> the lack of battery
2016-03-25 15:18 <wpwrak> then i don't get the pull-up
2016-03-25 15:18 <DocScrutinizer05> obviously this only works for battery removal, not for dieing battery
2016-03-25 15:20 <DocScrutinizer05> the pullup keeps GPIO at H, the C and pullup form a differentiator that pulls GPIO low when Vbatt drops steeply
2016-03-25 15:20 <DocScrutinizer05> removing a 1V battery will make GPIO drop by 1V
2016-03-25 15:21 <wpwrak> oh, series cap. hmm.
2016-03-25 15:21 <DocScrutinizer05> given you got no huge buffer capacitors etc in parallel to battery
2016-03-25 15:21 <DocScrutinizer05> the slower the fall time at Vbatt, the huger the series C you need
2016-03-25 15:22 <wpwrak> some 10 uF at least, a lot more on the other side of the regulator. so it may not drop all that fast
2016-03-25 15:23 <DocScrutinizer05> you honestly should thing of a simple battery removal electrical prefail contact
2016-03-25 15:23 <DocScrutinizer05> think*
2016-03-25 15:23 <wpwrak> in general, it's probably a bad idea on counting on anything to always drop quickly, because that would mean that we have huge leakage when in standby. something we'd try very hard to avoid.
2016-03-25 15:23 <wpwrak> if you can find me an off-the-shelf part ;-)
2016-03-25 15:23 <DocScrutinizer05> hmm, prolly easy enough
2016-03-25 15:24 <wpwrak> at least with digi-key, i already have a hard time finding _any_ contacts that may remotely work
2016-03-25 15:25 <DocScrutinizer05> I can see a two contacts to minus side of battery, one for power and one for prefail
2016-03-25 15:25 doomlord has joined #qi-hardware
2016-03-25 15:25 <wpwrak> battery holders and such, sure, no problem. (though i've never seen anything pre-fail) but they're also generally huge
2016-03-25 15:25 <wpwrak> in any case, i think we can rely on the low-voltage interrupt. it's designed precisely for this kind of situation.
2016-03-25 15:26 <DocScrutinizer05> just test it
2016-03-25 15:26 <wpwrak> on interrupt, immediately cut all high consumers, then yuo have plenty of time for the remaining cleanup
2016-03-25 15:26 <DocScrutinizer05> test it! :-)
2016-03-25 15:27 <wpwrak> one item deep down on the to do list ;-)
2016-03-25 15:27 <DocScrutinizer05> on interrupt, cut all consumers, then toggle a GPIO by 10kHz and count the pulses
2016-03-25 15:28 <DocScrutinizer05> next step: write one dword to storage per pulse
2016-03-25 15:28 <DocScrutinizer05> next step: use scope to check for any glitches on ADC/GPIO
2016-03-25 15:28 <wpwrak> sure. as i said, deep down on the to do list. for now, i just assume that this approach works.
2016-03-25 15:31 <DocScrutinizer05> next step: do a calibration session with randomly chosen (or sweep) battery off times (use a PC-controlled power supply for example) and compare timing capacitor readout to an external timebase that tells you about the exact duration of the power-down period
2016-03-25 15:31 <wpwrak> back to the page 2 mod. so the diode would put charging under MCU control, solving potential issues with false starts
2016-03-25 15:31 <DocScrutinizer05> yes
2016-03-25 15:32 <wpwrak> it would not remove the page 2 issue of having the RC discharge to Vcc, which may or may not hold a significant residual voltage for a long time
2016-03-25 15:32 <DocScrutinizer05> a schottky should allow discharge down to at least 0.6V
2016-03-25 15:33 <DocScrutinizer05> hmm, harly anything you can do about that, unless you use a normally-on component
2016-03-25 15:33 <wpwrak> much lower. Vf -> 0 V for If -> 0 A
2016-03-25 15:33 <DocScrutinizer05> really? didn't know
2016-03-25 15:33 <DocScrutinizer05> even better
2016-03-25 15:33 <wpwrak> page 3 solves that. it used GND as discharge reference, using the FET do couple Vcc "digitally"
2016-03-25 15:34 <DocScrutinizer05> the FET doesn't work
2016-03-25 15:34 <wpwrak> why not ?
2016-03-25 15:34 <DocScrutinizer05> it's no normally-on component unless you use depletion type
2016-03-25 15:35 <wpwrak> look at how it's used. when Vcc drops below Vc1 - Vgs(th), it opens discharging
2016-03-25 15:35 <DocScrutinizer05> honestly, whatever nasty effects you expect to see from residual VDD or whatever, do you really think they can't get calibrated out?
2016-03-25 15:36 <DocScrutinizer05> you're severely overengineering this
2016-03-25 15:36 <wpwrak> i don't know
2016-03-25 15:36 <wpwrak> if they're easy to calibrate out, then we can just use page 2 as is. doesn't even need the diode
2016-03-25 15:38 <DocScrutinizer05> page two has no advantages but severe disadvantages
2016-03-25 15:38 <DocScrutinizer05> trade in R1 for a schottky diode and have a much better design
2016-03-25 15:39 <DocScrutinizer05> you can't calibrate out user interaction aka bouncing etc during battery insertion
2016-03-25 15:40 <DocScrutinizer05> which btw is also a problem of p.3
2016-03-25 15:41 <DocScrutinizer05> while charging is under CPU control on p.3, discharging isn't
2016-03-25 15:41 <wpwrak> yes, also R1 limits the effect of short Vcc upsets (caused by user fumbling)
2016-03-25 15:41 <wpwrak> and if the upsets are prolonged, then both lose anyway, R1 or diode
2016-03-25 15:42 <DocScrutinizer05> well, R1 is prone to multiple CPU startups
2016-03-25 15:43 <wpwrak> also D1 gets "stopped" when there is enough juice
2016-03-25 15:43 <DocScrutinizer05> honestly, there's no visible advantage of p.2 original over the diode solution
2016-03-25 15:44 <wpwrak> simplicity :)
2016-03-25 15:44 <DocScrutinizer05> holler if you think otherwise
2016-03-25 15:44 <DocScrutinizer05> citation needed
2016-03-25 15:44 <DocScrutinizer05> I count same number of components
2016-03-25 15:45 <wpwrak> R is_simpler D // compare data sheet size :)
2016-03-25 15:45 <DocScrutinizer05> and 'simplicity' only means you have less control
2016-03-25 15:45 <DocScrutinizer05> sorry, afk
2016-03-25 15:45 <DocScrutinizer05> this isn't productive
2016-03-25 15:48 <wpwrak> btw, it would seem safer to place a diode in series with R1 instead of growing R2. this would allow keeping R2 voltage variations caused by GPIO leakage small
2016-03-25 15:50 <wpwrak> GPIO leakage is highly temperature-sensitive, while we could make resistors and such fairly temperature tolerant. besides, R and C would be affected by ambient while GPIO leakage is affected by chip temperature
2016-03-25 15:56 <DocScrutinizer05> as already mentioned you have a very accurate probing method for voltage on C1 by discharging it for a defined time via defined R and see the relative difference
2016-03-25 15:57 <DocScrutinizer05> hmm, dunno, maybe that's nonsense
2016-03-25 15:58 <DocScrutinizer05> anyway chip tempwerature won't vary that much during 1 minute of battery change
2016-03-25 15:59 <DocScrutinizer05> and about your expected accuracy, are you sure your timer will be more accurate during 24h than this mechanism's absulte error (in seconds) introduced during one minute?
2016-03-25 16:01 <DocScrutinizer05> 1% of error during 1 minute are 600ms
2016-03-25 16:01 <DocScrutinizer05> I hardly have any independant clock that's so accurate during 24h
2016-03-25 16:01 <wpwrak> samples are also needed for the occasional calibration. i think we need this. e.g., imagine someone putting their anelok in bright sunlight. that might trouble the cap enough to matter.
2016-03-25 16:02 <wpwrak> e.g., X5R can vary some 15% over 140 C temp range. already a 10 C change would be 1%
2016-03-25 16:02 <DocScrutinizer05> not when you calibrate prior to shutdown, as suggested
2016-03-25 16:03 <wpwrak> i don't think i have time for a full calibration before shutdown
2016-03-25 16:03 <DocScrutinizer05> I honestly don't get where in the product property specs there's the requirement that user doesn't need to announce battery swapping
2016-03-25 16:04 <wpwrak> no way ;-)
2016-03-25 16:05 <wpwrak> this is a device for humans who expect it to "just work", not robots who love executing 1024 item checklists ;-)
2016-03-25 16:05 <DocScrutinizer05> do you also have a requirement device enters waterproof mode before it hits the surface of toilet water?
2016-03-25 16:05 <wpwrak> waterproofing would be "nice to have". but that needs a lot more money.
2016-03-25 16:05 <DocScrutinizer05> for any user expecting "just works" it's the most natural thing to adjust time after battery swap
2016-03-25 16:06 <wpwrak> yeah, countless VCR 00:00 were living proof that adjusting the time is the most natural thing ;-))
2016-03-25 16:06 <DocScrutinizer05> for those even starting to think about why that's needed, they will be more than happy with a "prepare for batswap" function
2016-03-25 16:07 <DocScrutinizer05> your users need to adjust time at least monthly anyway
2016-03-25 16:07 <wpwrak> i don't expect people to actually understand how, say, TOTP works. think of the authentication tokens you may have. they usually just have one button -> number -> done
2016-03-25 16:08 <DocScrutinizer05> I'd expect according to your accuracy requirements (wheter nice-to-have or madatory) they have to do it even twice a week
2016-03-25 16:09 <DocScrutinizer05> aiui yiour 'rtc' is based on system clock oscillator, right?
2016-03-25 16:09 <wpwrak> on a 32.768 kHz crystal, yes. typically 10 ppm
2016-03-25 16:10 <DocScrutinizer05> those are generally not made to be extraordinarily immune against detuning by temperature variations etc
2016-03-25 16:11 <DocScrutinizer05> just test it
2016-03-25 16:11 <DocScrutinizer05> let your rtc MCU run for a week in 24°C, then another week at 8°C, check accuracy of time after each week
2016-03-25 16:12 <wpwrak> something like 16 ppm for a 20 K change in the example of the citizen CM315D series
2016-03-25 16:12 <wpwrak> (just to pick an easy to find one)
2016-03-25 16:12 <DocScrutinizer05> just check that this is meant for no other conditions changing
2016-03-25 16:13 <DocScrutinizer05> you yourself noted that even leakage curent of chip changes with temperature
2016-03-25 16:13 <wpwrak> also, the RTC can be synchronized when connected to a PC with accurate time (e.g., NTP). so occasional corrections are not a problem
2016-03-25 16:13 <DocScrutinizer05> you know those crytals are tuned by capacitive and also resistive damping
2016-03-25 16:14 <DocScrutinizer05> when occasional time correc tions are no problem, that why the hassle to keep time with a 1% error during that 1 minute of swapping?
2016-03-25 16:15 <wpwrak> because it may be some time until the next occasional correction comes along
2016-03-25 16:15 <DocScrutinizer05> so?
2016-03-25 16:15 <DocScrutinizer05> worst case you're off an additional 30s then
2016-03-25 16:15 <DocScrutinizer05> until next correction
2016-03-25 16:15 <DocScrutinizer05> with a 10% accuracy even just 6s
2016-03-25 16:16 <wpwrak> the basic idea is that anelok is self-sufficient. so if you decide to go "off the grid" for a few weeks, that should be okay.
2016-03-25 16:16 <DocScrutinizer05> prolly well below what the clock had on systematic error anyway
2016-03-25 16:16 <wpwrak> 30 s would be the time step of TOTP. so that's probably already too much.
2016-03-25 16:16 <DocScrutinizer05> I don't see the point
2016-03-25 16:17 <wpwrak> also, there may be pickier protocols. (and also TOTP can use shorter intervals)
2016-03-25 16:17 <DocScrutinizer05> then you got a problem. This thing won't be sufficiently accurate to keep time to a precision significantly better than 30s per 4 weeks
2016-03-25 16:18 <DocScrutinizer05> what the heck is TOTP? do I need to press two buttons in sync?
2016-03-25 16:18 <wpwrak> naw. look at watches. they certainly do much better than 30 s / 4 wk
2016-03-25 16:18 <DocScrutinizer05> you think so?
2016-03-25 16:19 <wpwrak> definitely
2016-03-25 16:19 <DocScrutinizer05> maybe when calibrated to your particular usage pattern and climate
2016-03-25 16:19 <wpwrak> e.g., my wristwatch is now about 1 minute off. the last time i set it must have been when returning from berlin. so that's 1 min / 6 months.
2016-03-25 16:20 <DocScrutinizer05> wristwatch is basically a temperature stabilized oscillator
2016-03-25 16:21 <DocScrutinizer05> and works with all the same voltage etc all the time
2016-03-25 16:21 <wpwrak> voltage is pretty constant in anelok as well
2016-03-25 16:22 <DocScrutinizer05> you still missed to answer my question how a protocol needing human interaction (I.E. no connection to a PC that serves as time stratum) can need precisions of <30s
2016-03-25 16:24 <DocScrutinizer05> I only can figure a "press enter and the trigger button on your dongle the very same moment now"
2016-03-25 16:24 doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
2016-03-25 16:24 <DocScrutinizer05> "then enter the number the dongle shows you, and please hurry"
2016-03-25 16:26 <wpwrak> heh :) yes, the total tolerance may be in the order of 60-90 s. but most of that is for the human. so we shouldn't be too generous with the errors the machine makes
2016-03-25 16:28 <DocScrutinizer05> I'd prefer the machine makes a constant error of +150s into the future and tells me at which time on PC's clock I have to hit the enter key
2016-03-25 16:28 doomlord has joined #qi-hardware
2016-03-25 16:28 <wpwrak> (http://joerg.cloud-7.de/share-service/DSCF1916.JPG) thanks ! actually, i should shrink it a bit. that thing is huge ...
2016-03-25 16:30 <DocScrutinizer05> or even a user selectable positive offset between 60 and 600 seconds
2016-03-25 16:31 <DocScrutinizer05> when using a clumsy touchscreen HID I might need more than 90s
2016-03-25 16:32 <DocScrutinizer05> however I can hit enter on a particular time displayed on such clumsy HID, rather precisely
2016-03-25 16:33 <DocScrutinizer05> and worst case I could generate the TOTP for next day, 4:45:00 when I'm at the beach and definitely have no anelok with me
2016-03-25 16:34 <DocScrutinizer05> IOW the device doesn't need the exact time, the user needs the exact time and they get that from the HID where they eneter the TOTP
2016-03-25 16:34 <wpwrak> naw, things don't work that way :)
2016-03-25 16:35 <DocScrutinizer05> the only probelm is to keep local virtual time on anelok known to user
2016-03-25 16:36 <DocScrutinizer05> huh? why? what can stop me from setting anelok's local time to 2016-05-01 13:00 right now and generate a TOTP token that I could use at exactly that date&time
2016-03-25 16:38 <DocScrutinizer05> or is this even a challenge-response thing? in that case a 30s precision (or even 90) is pretty tough to meet
2016-03-25 16:38 <DocScrutinizer05> unless you connect the anelok to PC, and in this case the device's local time is no concern at all
2016-03-25 16:39 <wpwrak> oh, sure you can do that. but the typical use is different, simpler.
2016-03-25 16:41 <DocScrutinizer05> whatever is the simpler usecase, I'd expect such dongle to not only show me the token but also the time(span) for which it's valid. I'd disadjust the device's local time a maybe 120s to the future then, on purpose
2016-03-25 16:42 <wpwrak> unrelated, we've come a long way: https://www.kickstarter.com/projects/339005690/bento-lab-a-dna-laboratory-for-everybody
2016-03-25 16:44 <wpwrak> the token doesn't know the real validity interval. at best, it could tell you a nominal interval. but the server may use a larger interval, and the token doesn't know the time offset. also, i don't think the server normally provides complementary information or find-grained synchronization to actually determine these parameters
2016-03-25 16:45 <wpwrak> but of course, you could make your own TOTP implementation that exposes all this, why not
2016-03-25 16:50 <DocScrutinizer05> hey, that's moot. When the server doesn't provide info then it's using defaults and UTC, both of which is known and available either by common knowledge or from a clock on pretty much any terminal you would use to enter such TOTP
2016-03-25 16:51 <DocScrutinizer05> and displaying the local time along with the token that got generated at that local time is no witchcraft
2016-03-25 16:52 <wpwrak> there are hidden parameters. e.g., you don't know how many time step intervals the server's tolerance window is
2016-03-25 16:52 <DocScrutinizer05> so what?
2016-03-25 16:53 <wpwrak> so not everything that's going on at the server is known
2016-03-25 16:53 <DocScrutinizer05> does that invalidate a token generated at 22:11:00 local time, when said token is used at 22:11:00 UTC?
2016-03-25 16:54 <DocScrutinizer05> and when my local time is 5 minutes ahead of UTC, how would that complicate things for me?
2016-03-25 16:55 <wpwrak> tokens and server use the same epoch. local time zone doesn't enter the equation :)
2016-03-25 16:55 <DocScrutinizer05> I can *guess* if server uses 10s windows or 2 minutes windows, however I'm pretty certainly capable to enter the token during those supposedly 5 minutes and hit enter at 22:11:0x of terminal's UTC
2016-03-25 16:56 <DocScrutinizer05> ohmy
2016-03-25 16:56 <DocScrutinizer05> you know of that weird timezone that' 23minutes 55seconds off from UTC?
2016-03-25 16:56 <DocScrutinizer05> me not
2016-03-25 16:57 <wpwrak> i'm not sure what scenario you're trying to construct. maybe have a look at https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm
2016-03-25 16:57 <wpwrak> this explains the basics. it's pretty simple, really
2016-03-25 16:57 <DocScrutinizer05> no, I don't need that
2016-03-25 16:57 doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
2016-03-25 16:58 <DocScrutinizer05> I'm absiolutely sure a dongle should display the (device)local time together with a TOTP token, and I know how to use that and I know I wouldn't bother when said local time is a 3 to 5 minutes off into the future
2016-03-25 16:58 <wpwrak> and here is its sibling that doesn't use time: https://en.wikipedia.org/wiki/HMAC-based_One-time_Password_Algorithm
2016-03-25 17:00 <DocScrutinizer05> you're trying to describe and enforce user's behavior by a RFC, I want to let user know what's the RFC and *them* taking care that those requirements are met
2016-03-25 17:01 <DocScrutinizer05> where requirement is: enter a TOTP at a quite precise UTC time
2016-03-25 17:02 <DocScrutinizer05> you define "user must not take longer than NN seconds", I say "tell user that the token starts to be valid at $timestamp"
2016-03-25 17:04 doomlord has joined #qi-hardware
2016-03-25 17:04 <wpwrak> the normal usage scenario is that you press a button, get a number, enter the number, and you're in. it makes no sense to force users to worry about implementation details just to avoid getting the technology right. i mean, tokens exist and they work.
2016-03-25 17:05 <wpwrak> if you want to play with time shift, sure, why not. but that's a different usage scenario
2016-03-25 17:07 <DocScrutinizer05> WTF, you can still do this, even when the dongle tells the timestamp of the token
2016-03-25 17:07 <wpwrak> btw, battery reversal et al: http://lists.en.qi-hardware.com/pipermail/discussion/2016-March/011016.html
2016-03-25 17:08 <DocScrutinizer05> another case of "we don't need that"?
2016-03-25 17:08 <wpwrak> what good would be knowing the timestamp ? i think what you want is time shift, no ?
2016-03-25 17:08 <DocScrutinizer05> ohmy
2016-03-25 17:09 <DocScrutinizer05> I guess I'll raher keep my TOTP tokens in a excel list, one for each 30s window of the next 5 months
2016-03-25 17:10 <wpwrak> e.g., if you know that tomorrow at 12:00 you'll want to use the token, you could generate the code it would show at that time, write it down and remember it. then, tomorrow at 12:00 you can use that code, irrespective of whether you have access to the token.
2016-03-25 17:10 <DocScrutinizer05> I don't like the approach of "why do you want that? we don't need that"
2016-03-25 17:10 <wpwrak> sure, you could precalculate all the codes :)
2016-03-25 17:11 doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
2016-03-25 17:11 <DocScrutinizer05> and I will fill a canon with anelok when it suffers from a maladjusted time and I block my account due to 3 "wrong" tokens in series
2016-03-25 17:12 <wpwrak> that is, if you have access to the secret. that's a given with any open TOTP implementations (google, etc.), i.e., anything you'd be able to use with anelok
2016-03-25 17:14 <wpwrak> the token you get from some banks however wouldn't let you time shift since it doesn't reveal the secret. so there you must have physical possession of the token at the time of use.
2016-03-25 17:15 doomlord has joined #qi-hardware
2016-03-25 17:15 <wpwrak> wolfspraul: funny: http://lists.en.qi-hardware.com/pipermail/discussion/2016-March/011016.html -> %(qi-html-head)s %(qi-html-body-top)s  and at the bottom  %(qi-html-body-bottom)s :)
2016-03-25 17:19 <DocScrutinizer05> I think you again didn't read half of what I said, despite it wasn't a wall of text but a dialog. I said I'd adjust my anelok time a 3 minutes to thee future and then take all the time I need to enter the token and press enter a 10s after the token-valid point in UTC time arrived
2016-03-25 17:21 <DocScrutinizer05> this however either needs a ultraprecise anelok time and a clumsy cross check with UTC on PC while anelok generates the token, plus some time math done in my brain, or simply a timestamp displayed with token by anelok
2016-03-25 17:22 <DocScrutinizer05> those who don't want to use that feature simply adjust their local anelok time to UTC and ignore the timestamp display (unless they want to make sure the anelok time is actually still correct)
2016-03-25 17:27 <wpwrak> sure, you're free to do this. but how would that matter for other users ? anelok has to work in "normal" usage scenarios. if you invent a procedure that allows you to compensate for time errors that's nice, but it's not something normal users would have to be concerned about. so even if you may be able to work with inaccurate time, most of the rest of the world won't. thus timekeeping has to be sufficiently accurate.
2016-03-25 17:29 <wpwrak> and as long as your operational parameters stay in the "normal" bracket, you thus won't need your sophisticated protocol either. but yes, if you plan to vanish in the jungle for a few years and then expect to come out, walk straight to the next PC, and use your token, then this may be quite useful :)
2016-03-25 17:53 <DocScrutinizer05> sophisticated protocol? please elaborate
2016-03-25 17:54 <DocScrutinizer05> and no, this is useful when using nasty clumsy terminals that take longer than 30s to enter the token
2016-03-25 17:55 doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
2016-03-25 17:55 <DocScrutinizer05> it's also useful to build trust into anelok since at each transaction you can implicitly check if time is correct, without any 'sophisticated protocol'
2016-03-25 17:56 <DocScrutinizer05> and finally it's useful to mitigate damage done when trust into anelok time is occasionally unjistified maybe
2016-03-25 17:58 <DocScrutinizer05> it's simply a matter similar to having a oil pressure meter for car engine instead of simply a red warning lamp showing "oil low!°
2016-03-25 17:59 <DocScrutinizer05> the only 'rationale' to not show timestamp is a "this will confuse users", something that never panned out so far
2016-03-25 18:00 <DocScrutinizer05> and particularly showing timestamp will _not_ stop anelok from "working for normal users"
2016-03-25 18:01 <DocScrutinizer05> I also didn't argue for neglecting to keep accurate time in anelok
2016-03-25 18:02 <DocScrutinizer05> au contraire I expect it won't always handle this duty sufficently good for me to feel I could do without such timestamp shown
2016-03-25 18:05 doomlord has joined #qi-hardware
2016-03-25 18:07 <DocScrutinizer05> I seen to many dirty battery contacts or batteries falling out of devices and devices getting set up by RF or ESD, to trust in anelok's time without checking it each time I gamble with access to my account which can get blocked when anelok's time is off a little bit
2016-03-25 18:10 <DocScrutinizer05> just for good measure you should not only provide timestamp but also suggest users compare it to UTC when using anelok
2016-03-25 18:10 <DocScrutinizer05> the way *how* or *if* they do is up to them then
2016-03-25 18:29 doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
2016-03-25 18:36 <DocScrutinizer05> maybe you find the analogy to providing md5sum for downloads convincing
2016-03-25 18:37 <DocScrutinizer05> sure you should try to get error free transmission of data, nevertheless you're supposed to check with md5sum
2016-03-25 18:39 doomlord has joined #qi-hardware
2016-03-25 18:54 <wpwrak> if anelok loses time, then it will be able to tell that. i.e., if Vc1 is too low. and yes, there has to be a way to manually set the time. anelok should be able to be fully usable also if it never communicates directly with another computer.
2016-03-25 18:54 <wpwrak> i know this is very retro. zeitgeist would dictate that you need at least a permanent connection to some cloud service ;-)
2016-03-25 18:54 <whitequark> you're designing in bluetooth, right?
2016-03-25 18:55 <whitequark> that would cover a massive amount of user devices, given how every laptop and every smartphone has one
2016-03-25 18:55 <whitequark> well, less than massive, if you restrict yourself to BLE only
2016-03-25 18:55 <whitequark> but still a lot
2016-03-25 19:09 sandeepkr_ has joined #qi-hardware
2016-03-25 19:12 sandeepkr has quit [Read error: No route to host]
2016-03-25 19:12 sandeepkr__ has joined #qi-hardware
2016-03-25 19:15 sandeepkr_ has quit [Read error: No route to host]
2016-03-25 19:16 sandeepkr has joined #qi-hardware
2016-03-25 19:16 sandeepkr__ has quit [Read error: No route to host]
2016-03-25 19:16 <DocScrutinizer05> ((if anelok loses time, then it will be able to tell that.)) supervising the supervisors. A lamp showing lamp defects. I suggest the oil pressure dial instead
2016-03-25 19:16 sandeepkr_ has joined #qi-hardware
2016-03-25 19:19 <DocScrutinizer05> while anelok might (or might not) be able to detect when it loses time completely due to battery removal or CPU reset, it has no chance to detect any of the more subtle problems that could arise from bad PC time it got synced to, over massive detuning of the crystal by drop shock, to random noise content of the time registers after ESD or RF interference
2016-03-25 19:19 <DocScrutinizer05> a simple display of timestamp together with the token will be the most effective and also most natural way to cope with all this
2016-03-25 19:20 sandeepkr has quit [Ping timeout: 264 seconds]
2016-03-25 19:21 <DocScrutinizer05> it even helps to detect e.g. user narcolepsy which caused a 10 minutes getting lost unnoticed between generating the the token and actually using it
2016-03-25 19:22 <DocScrutinizer05> or make that "during phonecall I completely forgot the time, thought it were just 2 minutes"
2016-03-25 19:23 <DocScrutinizer05> honestly, what's wrong with displaying the timestamp of generation time together with the token?
2016-03-25 19:35 sandeepkr_ has quit [Ping timeout: 248 seconds]
2016-03-25 19:47 solrize has quit [Ping timeout: 248 seconds]
2016-03-25 21:30 doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
2016-03-25 22:44 GonZo2000 has joined #qi-hardware
2016-03-25 22:44 GonZo2000 has joined #qi-hardware
2016-03-25 23:27 dandon has quit [Ping timeout: 260 seconds]
2016-03-25 23:32 dandon has joined #qi-hardware