#qi-hardware IRC log for Friday, 2016-03-25

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 flash05:50
wpwrak(fancy mechanics) naw, i try to keep things simple. no bespoke parts if not absolutely unavoidable. i'm not apple or samsung ;-)05:53
wpwrakTd 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, respectively05:55
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 it05:58
wpwrak(ADC on battery) i have that. ron already suggested it a few days ago ;-)05:59
wpwrak(VDD by booster) yes05:59
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 experiments06:03
kristianpaulwpwrak: http://www.bristol-seds.co.uk/pico-tracker/06:08
wpwrakneeds a car-mounted variant, then you can go breaking bad ;-)06:15
wpwrakDocScrutinizer05: 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.06:23
wpwrakthis would be more robust with respect to unpredictably decaying rails because the threshold would be fairly high, where the rail should still collapse quickly06:24
wpwraklike to C1 to VDD approach, discharging would only be needed for calibration06:25
wpwrakDocScrutinizer05: 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 ?07:02
wpwrakDocScrutinizer05: 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.pdf08:29
DocScrutinizer05yes, the link is medium-term stable10:27
DocScrutinizer05please use http://joerg.cloud-7.de/share-service/DSCF1916.JPG10:28
DocScrutinizer05or copy the photo to wherever you like10:29
DocScrutinizer05http://downloads.qi-hardware.com/people/werner/anelok/tmp/time-backup-draft-20160325.pdf page 3: I wonder how wide the operational range of Vc113:58
DocScrutinizer05you need to consider it drops over time, so eventually the FET will close due to insufficient Vgs13:58
DocScrutinizer05unless of course you use a depletion type FET14:01
DocScrutinizer05aka "normally conducting"14:01
wpwrakah, 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.14:05
wpwrak s/MOSFET/enhancement mode MOSFET/14:06
wpwraklemme see what characteristics the depletion critters have.  never used them.14:07
DocScrutinizer05well, the most relevant property of depletion type in this context is: with Vgs=0 (or floating) it's in conducting mode14:11
wpwrakp-channel depletion doesn't even seem to exist in the wild. good. one choice less to worry about ;-)14:12
DocScrutinizer05depletion types are significantly less comman than enrichment types14:13
wpwraklooking at n-channel, it seems to be pretty hard to get them to actually close14:13
wpwrakyes. i found this intro: http://www.aldinc.com/pdf/IntroDepletionModeMOSFET.pdf14:13
wpwrakalso, a digi-key search shows no rich pickings :)14:14
wpwraknaw, but i think it should work okay with a regular p-FET14:15
DocScrutinizer05not convinced14:16
wpwraklet's see ... yeah, need to increase C1 a little14:27
DocScrutinizer05yeah, like factor 10 or 5014:27
wpwrakif we cut off at, say, 1.5 V, then ... 33 uF would give us 86 s14:27
DocScrutinizer05Vth is higher than 1.5V14:28
wpwrakthere are plenty of FETs with Vgs(th) < 1.5 V14:28
DocScrutinizer05and you discharge a 3V to GND via R, while the discharge stops at 2V (Vgs_th)14:28
DocScrutinizer05honestly what's wrong with a depletion type?14:29
DocScrutinizer05it closed when VDD good, and opens when VDD ~zero14:30
wpwrakthere is one with Vgs(th) = 1.2 V for 1.5 uA: http://www.digikey.com/product-detail/en/infineon-technologies/BSS223PWH6327XTSA1/BSS223PWH6327XTSA1CT-ND/541000314:30
wpwrakand very low leakage, too14:31
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.14:37
DocScrutinizer05what is the problem we're trying to solve, to start with?14:41
DocScrutinizer05I think we're overengineering this14:42
wpwrakmeasuring power-off-time14:50
wpwrakideally with something around 1% accuracy14:51
DocScrutinizer05no, I mean why do we need the FET?14:52
wpwrakto cut the discharging while powered on. even a few uA are not nice at this point.14:55
DocScrutinizer05what's the problems we expect to find when in p.3 we make R1:DNP, R2: 3M314:55
wpwrakand then remove Q3, too ?14:56
wpwrakerr, Q114:56
DocScrutinizer05Sure! during CPU up we charge via GPIO14:56
DocScrutinizer05ooops, P.2 I meant14:57
wpwrakah. lemme see ...14:57
wpwrakthe GPIO is most likely closed when powered down. so it wouldn't discharge C114:58
DocScrutinizer05when CPU down, VDD is low and discharge worky via clamp diode in chip to VDD14:58
DocScrutinizer05works*14:58
wpwrakthere's no such clamp in the MCU. we could add one outside, though.14:59
DocScrutinizer05yep14:59
wpwrakthat would be similar to the FET. maybe better, though, due to Vf < Vgs(th)14:59
DocScrutinizer05prolly much better circuit characteristics than the FET solution14:59
DocScrutinizer05inaccuracy mostly depends on VDD drop time which isn't meant to be slower than max 2 seconds15:00
wpwrakah, 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.15:00
DocScrutinizer05hmm?15:00
wpwrakleakage 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 compensate15:02
DocScrutinizer05prolly not15:02
DocScrutinizer05should be pretty easy to compensate for15:02
DocScrutinizer05actually, calibrate15:02
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 bottom15:04
wpwrakso all the diode would do is cut out the top of the drop, which is the safest part15:04
DocScrutinizer05btw you have a very precise way to determine the true voltage of C, by measuring the discharge slew rate15:04
DocScrutinizer05sorry you completely lost me15:05
wpwraklet me rephrase it: how would your suggested modification of page 2 improve over what page 2 already does ?15:06
DocScrutinizer05it discharges during VDD slowly dropping to the point where CPU ceases to work15:07
DocScrutinizer05and it doesn't start charging on battery insertion while CPU still initializes15:07
DocScrutinizer05the latter is significant15:08
wpwrakinitialization time should be very predictable15:09
DocScrutinizer05since you have C pretty much discharged so voltage over R1 and thus charge rate is very high compared to the interesting residual charge15:09
wpwrakbut yes, there could be issues with contact bounce, as the user fumbles the battery into place15:09
DocScrutinizer05yes, for example15:10
DocScrutinizer05I'm pretty sure the simpler solution is the better (higher quality) one here15:11
DocScrutinizer05simply test it and see if it works15:11
DocScrutinizer05instead of introducing new problems while trying to solve percieved flaws of a already complex solution15:12
wpwraki 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 asleep15:12
DocScrutinizer05you need an interrupt as soon as battery gets removed15:13
DocScrutinizer05you can't make the CPU "call 911 when you lose conciousness"15:14
wpwrakthe MCU has two thresholds: a low-voltage threshold and a reset/brown-out threshold.15:15
DocScrutinizer05pretty 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 VDD15:16
DocScrutinizer05well, maybe you need a R voltage devicer to adjust the threshold/bias15:17
wpwrakyou mean pull-down ?15:17
DocScrutinizer05no, I mean pullup15:17
wpwrakah, i see15:17
wpwrakyou use the battery to pull down :)15:17
DocScrutinizer05yes15:17
DocScrutinizer05the lack of battery15:17
wpwrakthen i don't get the pull-up15:18
DocScrutinizer05obviously this only works for battery removal, not for dieing battery15:18
DocScrutinizer05the pullup keeps GPIO at H, the C and pullup form a differentiator that pulls GPIO low when Vbatt drops steeply15:20
DocScrutinizer05removing a 1V battery will make GPIO drop by 1V15:20
wpwrakoh, series cap. hmm.15:21
DocScrutinizer05given you got no huge buffer capacitors etc in parallel to battery15:21
DocScrutinizer05the slower the fall time at Vbatt, the huger the series C you need15:21
wpwraksome 10 uF at least, a lot more on the other side of the regulator. so it may not drop all that fast15:22
DocScrutinizer05you honestly should thing of a simple battery removal electrical prefail contact15:23
DocScrutinizer05think*15:23
wpwrakin 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.15:23
wpwrakif you can find me an off-the-shelf part ;-)15:23
DocScrutinizer05hmm, prolly easy enough15:23
wpwrakat least with digi-key, i already have a hard time finding _any_ contacts that may remotely work15:24
DocScrutinizer05I can see a two contacts to minus side of battery, one for power and one for prefail15:25
wpwrakbattery holders and such, sure, no problem. (though i've never seen anything pre-fail) but they're also generally huge15:25
wpwrakin any case, i think we can rely on the low-voltage interrupt. it's designed precisely for this kind of situation.15:25
DocScrutinizer05just test it15:26
wpwrakon interrupt, immediately cut all high consumers, then yuo have plenty of time for the remaining cleanup15:26
DocScrutinizer05test it! :-)15:26
wpwrakone item deep down on the to do list ;-)15:27
DocScrutinizer05on interrupt, cut all consumers, then toggle a GPIO by 10kHz and count the pulses15:27
DocScrutinizer05next step: write one dword to storage per pulse15:28
DocScrutinizer05next step: use scope to check for any glitches on ADC/GPIO15:28
wpwraksure. as i said, deep down on the to do list. for now, i just assume that this approach works.15:28
DocScrutinizer05next 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 period15:31
wpwrakback to the page 2 mod. so the diode would put charging under MCU control, solving potential issues with false starts15:31
DocScrutinizer05yes15:31
wpwrakit 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 time15:32
DocScrutinizer05a schottky should allow discharge down to at least 0.6V15:32
DocScrutinizer05hmm, harly anything you can do about that, unless you use a normally-on component15:33
wpwrakmuch lower. Vf -> 0 V for If -> 0 A15:33
DocScrutinizer05really? didn't know15:33
DocScrutinizer05even better15:33
wpwrakpage 3 solves that. it used GND as discharge reference, using the FET do couple Vcc "digitally"15:33
DocScrutinizer05the FET doesn't work15:34
wpwrakwhy not ?15:34
DocScrutinizer05it's no normally-on component unless you use depletion type15:34
wpwraklook at how it's used. when Vcc drops below Vc1 - Vgs(th), it opens discharging15:35
DocScrutinizer05honestly, whatever nasty effects you expect to see from residual VDD or whatever, do you really think they can't get calibrated out?15:35
DocScrutinizer05you're severely overengineering this15:36
wpwraki don't know15:36
wpwrakif they're easy to calibrate out, then we can just use page 2 as is. doesn't even need the diode15:36
DocScrutinizer05page two has no advantages but severe disadvantages15:38
DocScrutinizer05trade in R1 for a schottky diode and have a much better design15:38
DocScrutinizer05you can't calibrate out user interaction aka bouncing etc during battery insertion15:39
DocScrutinizer05which btw is also a problem of p.315:40
DocScrutinizer05while charging is under CPU control on p.3, discharging isn't15:41
wpwrakyes, also R1 limits the effect of short Vcc upsets (caused by user fumbling)15:41
wpwrakand if the upsets are prolonged, then both lose anyway, R1 or diode15:41
DocScrutinizer05well, R1 is prone to multiple CPU startups15:42
wpwrakalso D1 gets "stopped" when there is enough juice15:43
DocScrutinizer05honestly, there's no visible advantage of p.2 original over the diode solution15:43
wpwraksimplicity :)15:44
DocScrutinizer05holler if you think otherwise15:44
DocScrutinizer05citation needed15:44
DocScrutinizer05I count same number of components15:44
wpwrakR is_simpler D // compare data sheet size :)15:45
DocScrutinizer05and 'simplicity' only means you have less control15:45
DocScrutinizer05sorry, afk15:45
DocScrutinizer05this isn't productive15:45
wpwrakbtw, 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 small15:48
wpwrakGPIO 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 temperature15:50
DocScrutinizer05as 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 difference15:56
DocScrutinizer05hmm, dunno, maybe that's nonsense15:57
DocScrutinizer05anyway chip tempwerature won't vary that much during 1 minute of battery change15:58
DocScrutinizer05and 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?15:59
DocScrutinizer051% of error during 1 minute are 600ms16:01
DocScrutinizer05I hardly have any independant clock that's so accurate during 24h16:01
wpwraksamples 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.16:01
wpwrake.g., X5R can vary some 15% over 140 C temp range. already a 10 C change would be 1%16:02
DocScrutinizer05not when you calibrate prior to shutdown, as suggested16:02
wpwraki don't think i have time for a full calibration before shutdown16:03
DocScrutinizer05I honestly don't get where in the product property specs there's the requirement that user doesn't need to announce battery swapping 16:03
wpwrakno way ;-)16:04
wpwrakthis is a device for humans who expect it to "just work", not robots who love executing 1024 item checklists ;-)16:05
DocScrutinizer05do you also have a requirement device enters waterproof mode before it hits the surface of toilet water?16:05
wpwrakwaterproofing would be "nice to have". but that needs a lot more money.16:05
DocScrutinizer05for any user expecting "just works" it's the most natural thing to adjust time after battery swap16:05
wpwrakyeah, countless VCR 00:00 were living proof that adjusting the time is the most natural thing ;-))16:06
DocScrutinizer05for those even starting to think about why that's needed, they will be more than happy with a "prepare for batswap" function16:06
DocScrutinizer05your users need to adjust time at least monthly anyway16:07
wpwraki 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 -> done16:07
DocScrutinizer05I'd expect according to your accuracy requirements (wheter nice-to-have or madatory) they have to do it even twice a week16:08
DocScrutinizer05aiui yiour 'rtc' is based on system clock oscillator, right?16:09
wpwrakon a 32.768 kHz crystal, yes. typically 10 ppm16:09
DocScrutinizer05those are generally not made to be extraordinarily immune against detuning by temperature variations etc16:10
DocScrutinizer05just test it16:11
DocScrutinizer05let your rtc MCU run for a week in 24°C, then another week at 8°C, check accuracy of time after each week16:11
wpwraksomething like 16 ppm for a 20 K change in the example of the citizen CM315D series16:12
wpwrak(just to pick an easy to find one)16:12
DocScrutinizer05just check that this is meant for no other conditions changing16:12
DocScrutinizer05you yourself noted that even leakage curent of chip changes with temperature16:13
wpwrakalso, the RTC can be synchronized when connected to a PC with accurate time (e.g., NTP). so occasional corrections are not a problem16:13
DocScrutinizer05you know those crytals are tuned by capacitive and also resistive damping16:13
DocScrutinizer05when occasional time correc tions are no problem, that why the hassle to keep time with a 1% error during that 1 minute of swapping?16:14
wpwrakbecause it may be some time until the next occasional correction comes along16:15
DocScrutinizer05so?16:15
DocScrutinizer05worst case you're off an additional 30s then16:15
DocScrutinizer05until next correction16:15
DocScrutinizer05with a 10% accuracy even just 6s16:15
wpwrakthe 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.16:16
DocScrutinizer05prolly well below what the clock had on systematic error anyway16:16
wpwrak30 s would be the time step of TOTP. so that's probably already too much.16:16
DocScrutinizer05I don't see the point16:16
wpwrakalso, there may be pickier protocols. (and also TOTP can use shorter intervals)16:17
DocScrutinizer05then you got a problem. This thing won't be sufficiently accurate to keep time to a precision significantly better than 30s per 4 weeks16:17
DocScrutinizer05what the heck is TOTP? do I need to press two buttons in sync?16:18
wpwraknaw. look at watches. they certainly do much better than 30 s / 4 wk16:18
DocScrutinizer05you think so?16:18
wpwrakdefinitely16:19
DocScrutinizer05maybe when calibrated to your particular usage pattern and climate16:19
wpwrake.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.16:19
DocScrutinizer05wristwatch is basically a temperature stabilized oscillator16:20
DocScrutinizer05and works with all the same voltage etc all the time16:21
wpwrakvoltage is pretty constant in anelok as well16:21
DocScrutinizer05you 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 <30s16:22
DocScrutinizer05I only can figure a "press enter and the trigger button on your dongle the very same moment now"16:24
DocScrutinizer05"then enter the number the dongle shows you, and please hurry"16:24
wpwrakheh :) 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 makes16:26
DocScrutinizer05I'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 key16:28
wpwrak(http://joerg.cloud-7.de/share-service/DSCF1916.JPG) thanks ! actually, i should shrink it a bit. that thing is huge ...16:28
DocScrutinizer05or even a user selectable positive offset between 60 and 600 seconds16:30
DocScrutinizer05when using a clumsy touchscreen HID I might need more than 90s16:31
DocScrutinizer05however I can hit enter on a particular time displayed on such clumsy HID, rather precisely16:32
DocScrutinizer05and 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 me16:33
DocScrutinizer05IOW 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 TOTP16:34
wpwraknaw, things don't work that way :)16:34
DocScrutinizer05the only probelm is to keep local virtual time on anelok known to user16:35
DocScrutinizer05huh? 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&time16:36
DocScrutinizer05or is this even a challenge-response thing? in that case a 30s precision (or even 90) is pretty tough to meet16:38
DocScrutinizer05unless you connect the anelok to PC, and in this case the device's local time is no concern at all16:38
wpwrakoh, sure you can do that. but the typical use is different, simpler.16:39
DocScrutinizer05whatever 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 purpose16:41
wpwrakunrelated, we've come a long way: https://www.kickstarter.com/projects/339005690/bento-lab-a-dna-laboratory-for-everybody16:42
wpwrakthe 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 parameters16:44
wpwrakbut of course, you could make your own TOTP implementation that exposes all this, why not16:45
DocScrutinizer05hey, 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 TOTP16:50
DocScrutinizer05and displaying the local time along with the token that got generated at that local time is no witchcraft16:51
wpwrakthere are hidden parameters. e.g., you don't know how many time step intervals the server's tolerance window is16:52
DocScrutinizer05so what?16:52
wpwrakso not everything that's going on at the server is known16:53
DocScrutinizer05does that invalidate a token generated at 22:11:00 local time, when said token is used at 22:11:00 UTC?16:53
DocScrutinizer05and when my local time is 5 minutes ahead of UTC, how would that complicate things for me?16:54
wpwraktokens and server use the same epoch. local time zone doesn't enter the equation :)16:55
DocScrutinizer05I 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 UTC16:55
DocScrutinizer05ohmy16:56
DocScrutinizer05you know of that weird timezone that' 23minutes 55seconds off from UTC?16:56
DocScrutinizer05me not16:56
wpwraki'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_Algorithm16:57
wpwrakthis explains the basics. it's pretty simple, really16:57
DocScrutinizer05no, I don't need that16:57
DocScrutinizer05I'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 future16:58
wpwrakand here is its sibling that doesn't use time: https://en.wikipedia.org/wiki/HMAC-based_One-time_Password_Algorithm16:58
DocScrutinizer05you'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 met17:00
DocScrutinizer05where requirement is: enter a TOTP at a quite precise UTC time17:01
DocScrutinizer05you define "user must not take longer than NN seconds", I say "tell user that the token starts to be valid at $timestamp"17:02
wpwrakthe 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.17:04
wpwrakif you want to play with time shift, sure, why not. but that's a different usage scenario17:05
DocScrutinizer05WTF, you can still do this, even when the dongle tells the timestamp of the token17:07
wpwrakbtw, battery reversal et al: http://lists.en.qi-hardware.com/pipermail/discussion/2016-March/011016.html17:07
DocScrutinizer05another case of "we don't need that"?17:08
wpwrakwhat good would be knowing the timestamp ? i think what you want is time shift, no ?17:08
DocScrutinizer05ohmy17:08
DocScrutinizer05I guess I'll raher keep my TOTP tokens in a excel list, one for each 30s window of the next 5 months17:09
wpwrake.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.17:10
DocScrutinizer05I don't like the approach of "why do you want that? we don't need that"17:10
wpwraksure, you could precalculate all the codes :)17:10
DocScrutinizer05and 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 series17:11
wpwrakthat 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 anelok17:12
wpwrakthe 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.17:14
wpwrakwolfspraul: 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 :)17:15
DocScrutinizer05I 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 arrived17:19
DocScrutinizer05this 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 anelok17:21
DocScrutinizer05those 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)17:22
wpwraksure, 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.17:27
wpwrakand 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 :)17:29
DocScrutinizer05sophisticated protocol? please elaborate17:53
DocScrutinizer05and no, this is useful when using nasty clumsy terminals that take longer than 30s to enter the token17:54
DocScrutinizer05it's also useful to build trust into anelok since at each transaction you can implicitly check if time is correct, without any 'sophisticated protocol'17:55
DocScrutinizer05and finally it's useful to mitigate damage done when trust into anelok time is occasionally unjistified maybe17:56
DocScrutinizer05it's simply a matter similar to having a oil pressure meter for car engine instead of simply a red warning lamp showing "oil low!°17:58
DocScrutinizer05the only 'rationale' to not show timestamp is a "this will confuse users", something that never panned out so far17:59
DocScrutinizer05and particularly showing timestamp will _not_ stop anelok from "working for normal users"18:00
DocScrutinizer05I also didn't argue for neglecting to keep accurate time in anelok18:01
DocScrutinizer05au contraire I expect it won't always handle this duty sufficently good for me to feel I could do without such timestamp shown18:02
DocScrutinizer05I 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 bit18:07
DocScrutinizer05just for good measure you should not only provide timestamp but also suggest users compare it to UTC when using anelok18:10
DocScrutinizer05the way *how* or *if* they do is up to them then18:10
DocScrutinizer05maybe you find the analogy to providing md5sum for downloads convincing18:36
DocScrutinizer05sure you should try to get error free transmission of data, nevertheless you're supposed to check with md5sum18:37
wpwrakif 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.18:54
wpwraki know this is very retro. zeitgeist would dictate that you need at least a permanent connection to some cloud service ;-)18:54
whitequarkyou're designing in bluetooth, right?18:54
whitequarkthat would cover a massive amount of user devices, given how every laptop and every smartphone has one18:55
whitequarkwell, less than massive, if you restrict yourself to BLE only18:55
whitequarkbut still a lot18:55
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 instead19:16
DocScrutinizer05while 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 interference19:19
DocScrutinizer05a simple display of timestamp together with the token will be the most effective and also most natural way to cope with all this19:19
DocScrutinizer05it even helps to detect e.g. user narcolepsy which caused a 10 minutes getting lost unnoticed between generating the the token and actually using it19:21
DocScrutinizer05or make that "during phonecall I completely forgot the time, thought it were just 2 minutes"19:22
DocScrutinizer05honestly, what's wrong with displaying the timestamp of generation time together with the token?19:23
--- Sat Mar 26 201600:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!