| 01:52.29 | *** join/#qi-hardware archang (~archang@111.198.29.53) |
| 02:17.34 | *** join/#qi-hardware archang (~archang@122.133.52.113.static.ximdns.com) |
| 03:05.09 | *** join/#qi-hardware archang (~archang@122.133.52.113.static.ximdns.com) |
| 03:06.04 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 04:00.47 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 04:22.19 | *** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 05:29.14 | *** join/#qi-hardware GeorgeHahn (~GeorgeHah@c-69-141-92-254.hsd1.nj.comcast.net) |
| 05:50.07 | 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 |
| 05:53.44 | wpwrak | (fancy mechanics) naw, i try to keep things simple. no bespoke parts if not absolutely unavoidable. i'm not apple or samsung ;-) |
| 05:55.36 | 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 |
| 05:58.33 | 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 |
| 05:59.03 | wpwrak | (ADC on battery) i have that. ron already suggested it a few days ago ;-) |
| 05:59.20 | wpwrak | (VDD by booster) yes |
| 06:03.42 | 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 |
| 06:07.20 | *** join/#qi-hardware arossdotme-planb (~zxy@host-92-26-242-129.as13285.net) |
| 06:08.40 | kristianpaul | wpwrak: http://www.bristol-seds.co.uk/pico-tracker/ |
| 06:15.14 | wpwrak | needs a car-mounted variant, then you can go breaking bad ;-) |
| 06:23.14 | 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. |
| 06:24.33 | 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 |
| 06:25.04 | wpwrak | like to C1 to VDD approach, discharging would only be needed for calibration |
| 06:26.14 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 07:02.01 | 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 ? |
| 07:49.12 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 08:29.13 | 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 |
| 08:34.46 | *** join/#qi-hardware fengling (~fengling@111.198.29.53) |
| 09:40.34 | *** join/#qi-hardware uwe_mobile (~uwe@static.173.76.9.176.clients.your-server.de) |
| 10:27.21 | DocScrutinizer05 | yes, the link is medium-term stable |
| 10:28.06 | DocScrutinizer05 | please use http://joerg.cloud-7.de/share-service/DSCF1916.JPG |
| 10:29.33 | DocScrutinizer05 | or copy the photo to wherever you like |
| 13:01.49 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 13:58.14 | 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 |
| 13:58.53 | *** join/#qi-hardware doomlord (~textual@host217-42-162-151.range217-42.btcentralplus.com) |
| 13:58.54 | DocScrutinizer05 | you need to consider it drops over time, so eventually the FET will close due to insufficient Vgs |
| 14:01.01 | DocScrutinizer05 | unless of course you use a depletion type FET |
| 14:01.47 | DocScrutinizer05 | aka "normally conducting" |
| 14:05.28 | 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. |
| 14:06.31 | wpwrak | <PROTECTED> |
| 14:07.37 | wpwrak | lemme see what characteristics the depletion critters have. never used them. |
| 14:11.29 | DocScrutinizer05 | well, the most relevant property of depletion type in this context is: with Vgs=0 (or floating) it's in conducting mode |
| 14:12.22 | wpwrak | p-channel depletion doesn't even seem to exist in the wild. good. one choice less to worry about ;-) |
| 14:13.34 | DocScrutinizer05 | depletion types are significantly less comman than enrichment types |
| 14:13.38 | wpwrak | looking at n-channel, it seems to be pretty hard to get them to actually close |
| 14:13.58 | wpwrak | yes. i found this intro: http://www.aldinc.com/pdf/IntroDepletionModeMOSFET.pdf |
| 14:14.09 | wpwrak | also, a digi-key search shows no rich pickings :) |
| 14:15.53 | wpwrak | naw, but i think it should work okay with a regular p-FET |
| 14:16.55 | DocScrutinizer05 | not convinced |
| 14:27.07 | wpwrak | let's see ... yeah, need to increase C1 a little |
| 14:27.57 | DocScrutinizer05 | yeah, like factor 10 or 50 |
| 14:27.59 | wpwrak | if we cut off at, say, 1.5 V, then ... 33 uF would give us 86 s |
| 14:28.19 | DocScrutinizer05 | Vth is higher than 1.5V |
| 14:28.52 | wpwrak | there are plenty of FETs with Vgs(th) < 1.5 V |
| 14:28.58 | DocScrutinizer05 | and you discharge a 3V to GND via R, while the discharge stops at 2V (Vgs_th) |
| 14:29.23 | DocScrutinizer05 | honestly what's wrong with a depletion type? |
| 14:30.13 | DocScrutinizer05 | it closed when VDD good, and opens when VDD ~zero |
| 14:30.51 | 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 |
| 14:31.11 | wpwrak | and very low leakage, too |
| 14:37.18 | 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:41.35 | DocScrutinizer05 | what is the problem we're trying to solve, to start with? |
| 14:42.26 | DocScrutinizer05 | I think we're overengineering this |
| 14:50.45 | wpwrak | measuring power-off-time |
| 14:51.01 | wpwrak | ideally with something around 1% accuracy |
| 14:52.42 | DocScrutinizer05 | no, I mean why do we need the FET? |
| 14:55.20 | wpwrak | to cut the discharging while powered on. even a few uA are not nice at this point. |
| 14:55.31 | DocScrutinizer05 | what's the problems we expect to find when in p.3 we make R1:DNP, R2: 3M3 |
| 14:56.49 | wpwrak | and then remove Q3, too ? |
| 14:56.57 | wpwrak | err, Q1 |
| 14:56.59 | DocScrutinizer05 | Sure! during CPU up we charge via GPIO |
| 14:57.13 | DocScrutinizer05 | ooops, P.2 I meant |
| 14:57.24 | wpwrak | ah. lemme see ... |
| 14:58.09 | wpwrak | the GPIO is most likely closed when powered down. so it wouldn't discharge C1 |
| 14:58.14 | DocScrutinizer05 | when CPU down, VDD is low and discharge worky via clamp diode in chip to VDD |
| 14:58.29 | DocScrutinizer05 | works* |
| 14:59.01 | wpwrak | there's no such clamp in the MCU. we could add one outside, though. |
| 14:59.08 | DocScrutinizer05 | yep |
| 14:59.26 | wpwrak | that would be similar to the FET. maybe better, though, due to Vf < Vgs(th) |
| 14:59.30 | DocScrutinizer05 | prolly much better circuit characteristics than the FET solution |
| 15:00.21 | DocScrutinizer05 | inaccuracy mostly depends on VDD drop time which isn't meant to be slower than max 2 seconds |
| 15:00.31 | 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. |
| 15:00.53 | DocScrutinizer05 | hmm? |
| 15:02.12 | 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 |
| 15:02.29 | DocScrutinizer05 | prolly not |
| 15:02.46 | DocScrutinizer05 | should be pretty easy to compensate for |
| 15:02.54 | DocScrutinizer05 | actually, calibrate |
| 15:04.03 | 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 |
| 15:04.30 | wpwrak | so all the diode would do is cut out the top of the drop, which is the safest part |
| 15:04.30 | DocScrutinizer05 | btw you have a very precise way to determine the true voltage of C, by measuring the discharge slew rate |
| 15:05.08 | DocScrutinizer05 | sorry you completely lost me |
| 15:06.14 | wpwrak | let me rephrase it: how would your suggested modification of page 2 improve over what page 2 already does ? |
| 15:07.08 | DocScrutinizer05 | it discharges during VDD slowly dropping to the point where CPU ceases to work |
| 15:07.44 | DocScrutinizer05 | and it doesn't start charging on battery insertion while CPU still initializes |
| 15:08.40 | DocScrutinizer05 | the latter is significant |
| 15:09.11 | wpwrak | initialization time should be very predictable |
| 15:09.21 | 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 |
| 15:09.50 | wpwrak | but yes, there could be issues with contact bounce, as the user fumbles the battery into place |
| 15:10.01 | DocScrutinizer05 | yes, for example |
| 15:11.05 | DocScrutinizer05 | I'm pretty sure the simpler solution is the better (higher quality) one here |
| 15:11.38 | DocScrutinizer05 | simply test it and see if it works |
| 15:12.26 | DocScrutinizer05 | instead of introducing new problems while trying to solve percieved flaws of a already complex solution |
| 15:12.44 | 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 |
| 15:13.34 | DocScrutinizer05 | you need an interrupt as soon as battery gets removed |
| 15:14.19 | DocScrutinizer05 | you can't make the CPU "call 911 when you lose conciousness" |
| 15:14.56 | *** join/#qi-hardware doomlord (~textual@host217-42-162-151.range217-42.btcentralplus.com) |
| 15:15.17 | wpwrak | the MCU has two thresholds: a low-voltage threshold and a reset/brown-out threshold. |
| 15:16.11 | 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 |
| 15:17.11 | DocScrutinizer05 | well, maybe you need a R voltage devicer to adjust the threshold/bias |
| 15:17.12 | wpwrak | you mean pull-down ? |
| 15:17.22 | DocScrutinizer05 | no, I mean pullup |
| 15:17.30 | wpwrak | ah, i see |
| 15:17.38 | wpwrak | you use the battery to pull down :) |
| 15:17.41 | DocScrutinizer05 | yes |
| 15:17.50 | DocScrutinizer05 | the lack of battery |
| 15:18.27 | wpwrak | then i don't get the pull-up |
| 15:18.48 | DocScrutinizer05 | obviously this only works for battery removal, not for dieing battery |
| 15:20.01 | DocScrutinizer05 | the pullup keeps GPIO at H, the C and pullup form a differentiator that pulls GPIO low when Vbatt drops steeply |
| 15:20.44 | DocScrutinizer05 | removing a 1V battery will make GPIO drop by 1V |
| 15:21.07 | wpwrak | oh, series cap. hmm. |
| 15:21.21 | DocScrutinizer05 | given you got no huge buffer capacitors etc in parallel to battery |
| 15:21.59 | DocScrutinizer05 | the slower the fall time at Vbatt, the huger the series C you need |
| 15:22.14 | wpwrak | some 10 uF at least, a lot more on the other side of the regulator. so it may not drop all that fast |
| 15:23.00 | DocScrutinizer05 | you honestly should thing of a simple battery removal electrical prefail contact |
| 15:23.05 | DocScrutinizer05 | think* |
| 15:23.05 | 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. |
| 15:23.33 | wpwrak | if you can find me an off-the-shelf part ;-) |
| 15:23.57 | DocScrutinizer05 | hmm, prolly easy enough |
| 15:24.28 | wpwrak | at least with digi-key, i already have a hard time finding _any_ contacts that may remotely work |
| 15:25.02 | DocScrutinizer05 | I can see a two contacts to minus side of battery, one for power and one for prefail |
| 15:25.12 | *** join/#qi-hardware doomlord (~textual@host217-42-162-151.range217-42.btcentralplus.com) |
| 15:25.21 | wpwrak | battery holders and such, sure, no problem. (though i've never seen anything pre-fail) but they're also generally huge |
| 15:25.59 | wpwrak | in any case, i think we can rely on the low-voltage interrupt. it's designed precisely for this kind of situation. |
| 15:26.28 | DocScrutinizer05 | just test it |
| 15:26.46 | wpwrak | on interrupt, immediately cut all high consumers, then yuo have plenty of time for the remaining cleanup |
| 15:26.59 | DocScrutinizer05 | test it! :-) |
| 15:27.15 | wpwrak | one item deep down on the to do list ;-) |
| 15:27.29 | DocScrutinizer05 | on interrupt, cut all consumers, then toggle a GPIO by 10kHz and count the pulses |
| 15:28.15 | DocScrutinizer05 | next step: write one dword to storage per pulse |
| 15:28.47 | DocScrutinizer05 | next step: use scope to check for any glitches on ADC/GPIO |
| 15:28.55 | wpwrak | sure. as i said, deep down on the to do list. for now, i just assume that this approach works. |
| 15:31.17 | 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 |
| 15:31.34 | wpwrak | back to the page 2 mod. so the diode would put charging under MCU control, solving potential issues with false starts |
| 15:31.46 | DocScrutinizer05 | yes |
| 15:32.12 | 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 |
| 15:32.16 | DocScrutinizer05 | a schottky should allow discharge down to at least 0.6V |
| 15:33.09 | DocScrutinizer05 | hmm, harly anything you can do about that, unless you use a normally-on component |
| 15:33.09 | wpwrak | much lower. Vf -> 0 V for If -> 0 A |
| 15:33.32 | DocScrutinizer05 | really? didn't know |
| 15:33.39 | DocScrutinizer05 | even better |
| 15:33.39 | wpwrak | page 3 solves that. it used GND as discharge reference, using the FET do couple Vcc "digitally" |
| 15:34.11 | DocScrutinizer05 | the FET doesn't work |
| 15:34.36 | wpwrak | why not ? |
| 15:34.42 | DocScrutinizer05 | it's no normally-on component unless you use depletion type |
| 15:35.42 | wpwrak | look at how it's used. when Vcc drops below Vc1 - Vgs(th), it opens discharging |
| 15:35.57 | DocScrutinizer05 | honestly, whatever nasty effects you expect to see from residual VDD or whatever, do you really think they can't get calibrated out? |
| 15:36.28 | DocScrutinizer05 | you're severely overengineering this |
| 15:36.34 | wpwrak | i don't know |
| 15:36.51 | wpwrak | if they're easy to calibrate out, then we can just use page 2 as is. doesn't even need the diode |
| 15:38.05 | DocScrutinizer05 | page two has no advantages but severe disadvantages |
| 15:38.35 | DocScrutinizer05 | trade in R1 for a schottky diode and have a much better design |
| 15:39.19 | DocScrutinizer05 | you can't calibrate out user interaction aka bouncing etc during battery insertion |
| 15:40.20 | DocScrutinizer05 | which btw is also a problem of p.3 |
| 15:41.07 | DocScrutinizer05 | while charging is under CPU control on p.3, discharging isn't |
| 15:41.38 | wpwrak | yes, also R1 limits the effect of short Vcc upsets (caused by user fumbling) |
| 15:41.58 | wpwrak | and if the upsets are prolonged, then both lose anyway, R1 or diode |
| 15:42.41 | DocScrutinizer05 | well, R1 is prone to multiple CPU startups |
| 15:43.24 | wpwrak | also D1 gets "stopped" when there is enough juice |
| 15:43.39 | DocScrutinizer05 | honestly, there's no visible advantage of p.2 original over the diode solution |
| 15:44.22 | wpwrak | simplicity :) |
| 15:44.25 | DocScrutinizer05 | holler if you think otherwise |
| 15:44.37 | DocScrutinizer05 | citation needed |
| 15:44.56 | DocScrutinizer05 | I count same number of components |
| 15:45.12 | wpwrak | R is_simpler D // compare data sheet size :) |
| 15:45.19 | DocScrutinizer05 | and 'simplicity' only means you have less control |
| 15:45.28 | DocScrutinizer05 | sorry, afk |
| 15:45.38 | DocScrutinizer05 | this isn't productive |
| 15:48.49 | 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 |
| 15:50.28 | 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 |
| 15:56.53 | 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 |
| 15:57.51 | DocScrutinizer05 | hmm, dunno, maybe that's nonsense |
| 15:58.22 | DocScrutinizer05 | anyway chip tempwerature won't vary that much during 1 minute of battery change |
| 15:59.30 | 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? |
| 16:01.14 | DocScrutinizer05 | 1% of error during 1 minute are 600ms |
| 16:01.36 | DocScrutinizer05 | I hardly have any independant clock that's so accurate during 24h |
| 16:01.57 | 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. |
| 16:02.54 | wpwrak | e.g., X5R can vary some 15% over 140 C temp range. already a 10 C change would be 1% |
| 16:02.58 | DocScrutinizer05 | not when you calibrate prior to shutdown, as suggested |
| 16:03.57 | wpwrak | i don't think i have time for a full calibration before shutdown |
| 16:03.57 | 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 |
| 16:04.29 | wpwrak | no way ;-) |
| 16:05.04 | wpwrak | this is a device for humans who expect it to "just work", not robots who love executing 1024 item checklists ;-) |
| 16:05.05 | DocScrutinizer05 | do you also have a requirement device enters waterproof mode before it hits the surface of toilet water? |
| 16:05.37 | wpwrak | waterproofing would be "nice to have". but that needs a lot more money. |
| 16:05.54 | DocScrutinizer05 | for any user expecting "just works" it's the most natural thing to adjust time after battery swap |
| 16:06.26 | wpwrak | yeah, countless VCR 00:00 were living proof that adjusting the time is the most natural thing ;-)) |
| 16:06.46 | DocScrutinizer05 | for those even starting to think about why that's needed, they will be more than happy with a "prepare for batswap" function |
| 16:07.15 | DocScrutinizer05 | your users need to adjust time at least monthly anyway |
| 16:07.59 | 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 |
| 16:08.06 | DocScrutinizer05 | I'd expect according to your accuracy requirements (wheter nice-to-have or madatory) they have to do it even twice a week |
| 16:09.14 | DocScrutinizer05 | aiui yiour 'rtc' is based on system clock oscillator, right? |
| 16:09.39 | wpwrak | on a 32.768 kHz crystal, yes. typically 10 ppm |
| 16:10.03 | DocScrutinizer05 | those are generally not made to be extraordinarily immune against detuning by temperature variations etc |
| 16:11.16 | DocScrutinizer05 | just test it |
| 16:11.58 | 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 |
| 16:12.04 | wpwrak | something like 16 ppm for a 20 K change in the example of the citizen CM315D series |
| 16:12.17 | wpwrak | (just to pick an easy to find one) |
| 16:12.39 | DocScrutinizer05 | just check that this is meant for no other conditions changing |
| 16:13.00 | DocScrutinizer05 | you yourself noted that even leakage curent of chip changes with temperature |
| 16:13.18 | 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 |
| 16:13.28 | DocScrutinizer05 | you know those crytals are tuned by capacitive and also resistive damping |
| 16:14.35 | 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? |
| 16:15.02 | wpwrak | because it may be some time until the next occasional correction comes along |
| 16:15.10 | DocScrutinizer05 | so? |
| 16:15.27 | DocScrutinizer05 | worst case you're off an additional 30s then |
| 16:15.39 | DocScrutinizer05 | until next correction |
| 16:15.59 | DocScrutinizer05 | with a 10% accuracy even just 6s |
| 16:16.28 | 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. |
| 16:16.36 | DocScrutinizer05 | prolly well below what the clock had on systematic error anyway |
| 16:16.52 | wpwrak | 30 s would be the time step of TOTP. so that's probably already too much. |
| 16:16.56 | DocScrutinizer05 | I don't see the point |
| 16:17.22 | wpwrak | also, there may be pickier protocols. (and also TOTP can use shorter intervals) |
| 16:17.42 | 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 |
| 16:18.18 | DocScrutinizer05 | what the heck is TOTP? do I need to press two buttons in sync? |
| 16:18.27 | wpwrak | naw. look at watches. they certainly do much better than 30 s / 4 wk |
| 16:18.38 | DocScrutinizer05 | you think so? |
| 16:19.11 | wpwrak | definitely |
| 16:19.23 | DocScrutinizer05 | maybe when calibrated to your particular usage pattern and climate |
| 16:19.58 | 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. |
| 16:20.44 | DocScrutinizer05 | wristwatch is basically a temperature stabilized oscillator |
| 16:21.22 | DocScrutinizer05 | and works with all the same voltage etc all the time |
| 16:21.51 | wpwrak | voltage is pretty constant in anelok as well |
| 16:22.45 | 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 |
| 16:24.06 | DocScrutinizer05 | I only can figure a "press enter and the trigger button on your dongle the very same moment now" |
| 16:24.57 | DocScrutinizer05 | "then enter the number the dongle shows you, and please hurry" |
| 16:26.17 | 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 |
| 16:28.13 | 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 |
| 16:28.14 | *** join/#qi-hardware doomlord (~textual@host217-42-162-151.range217-42.btcentralplus.com) |
| 16:28.18 | wpwrak | (http://joerg.cloud-7.de/share-service/DSCF1916.JPG) thanks ! actually, i should shrink it a bit. that thing is huge ... |
| 16:30.22 | DocScrutinizer05 | or even a user selectable positive offset between 60 and 600 seconds |
| 16:31.22 | DocScrutinizer05 | when using a clumsy touchscreen HID I might need more than 90s |
| 16:32.00 | DocScrutinizer05 | however I can hit enter on a particular time displayed on such clumsy HID, rather precisely |
| 16:33.01 | 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 |
| 16:34.02 | 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 |
| 16:34.59 | wpwrak | naw, things don't work that way :) |
| 16:35.13 | DocScrutinizer05 | the only probelm is to keep local virtual time on anelok known to user |
| 16:36.59 | 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 |
| 16:38.01 | DocScrutinizer05 | or is this even a challenge-response thing? in that case a 30s precision (or even 90) is pretty tough to meet |
| 16:38.42 | DocScrutinizer05 | unless you connect the anelok to PC, and in this case the device's local time is no concern at all |
| 16:39.03 | wpwrak | oh, sure you can do that. but the typical use is different, simpler. |
| 16:41.47 | 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 |
| 16:42.21 | wpwrak | unrelated, we've come a long way: https://www.kickstarter.com/projects/339005690/bento-lab-a-dna-laboratory-for-everybody |
| 16:44.57 | 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 |
| 16:45.16 | wpwrak | but of course, you could make your own TOTP implementation that exposes all this, why not |
| 16:50.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 |
| 16:51.53 | DocScrutinizer05 | and displaying the local time along with the token that got generated at that local time is no witchcraft |
| 16:52.18 | wpwrak | there are hidden parameters. e.g., you don't know how many time step intervals the server's tolerance window is |
| 16:52.26 | DocScrutinizer05 | so what? |
| 16:53.11 | wpwrak | so not everything that's going on at the server is known |
| 16:53.22 | DocScrutinizer05 | does that invalidate a token generated at 22:11:00 local time, when said token is used at 22:11:00 UTC? |
| 16:54.16 | DocScrutinizer05 | and when my local time is 5 minutes ahead of UTC, how would that complicate things for me? |
| 16:55.03 | wpwrak | tokens and server use the same epoch. local time zone doesn't enter the equation :) |
| 16:55.57 | 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 |
| 16:56.08 | DocScrutinizer05 | ohmy |
| 16:56.44 | DocScrutinizer05 | you know of that weird timezone that' 23minutes 55seconds off from UTC? |
| 16:56.55 | DocScrutinizer05 | me not |
| 16:57.17 | 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 |
| 16:57.27 | wpwrak | this explains the basics. it's pretty simple, really |
| 16:57.31 | DocScrutinizer05 | no, I don't need that |
| 16:58.40 | 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 |
| 16:58.41 | wpwrak | and here is its sibling that doesn't use time: https://en.wikipedia.org/wiki/HMAC-based_One-time_Password_Algorithm |
| 17:00.53 | 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 |
| 17:01.32 | DocScrutinizer05 | where requirement is: enter a TOTP at a quite precise UTC time |
| 17:02.22 | DocScrutinizer05 | you define "user must not take longer than NN seconds", I say "tell user that the token starts to be valid at $timestamp" |
| 17:04.21 | *** join/#qi-hardware doomlord (~textual@host217-42-162-151.range217-42.btcentralplus.com) |
| 17:04.40 | 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. |
| 17:05.04 | wpwrak | if you want to play with time shift, sure, why not. but that's a different usage scenario |
| 17:07.18 | DocScrutinizer05 | WTF, you can still do this, even when the dongle tells the timestamp of the token |
| 17:07.36 | wpwrak | btw, battery reversal et al: http://lists.en.qi-hardware.com/pipermail/discussion/2016-March/011016.html |
| 17:08.05 | DocScrutinizer05 | another case of "we don't need that"? |
| 17:08.37 | wpwrak | what good would be knowing the timestamp ? i think what you want is time shift, no ? |
| 17:08.47 | DocScrutinizer05 | ohmy |
| 17:09.49 | DocScrutinizer05 | I guess I'll raher keep my TOTP tokens in a excel list, one for each 30s window of the next 5 months |
| 17:10.25 | 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. |
| 17:10.26 | DocScrutinizer05 | I don't like the approach of "why do you want that? we don't need that" |
| 17:10.48 | wpwrak | sure, you could precalculate all the codes :) |
| 17:11.44 | 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 |
| 17:12.25 | 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 |
| 17:14.52 | 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. |
| 17:15.47 | *** join/#qi-hardware doomlord (~textual@host217-42-162-151.range217-42.btcentralplus.com) |
| 17:15.58 | 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 :) |
| 17:19.36 | 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 |
| 17:21.41 | 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 |
| 17:22.47 | 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) |
| 17:27.06 | 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. |
| 17:29.12 | 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 :) |
| 17:53.52 | DocScrutinizer05 | sophisticated protocol? please elaborate |
| 17:54.53 | DocScrutinizer05 | and no, this is useful when using nasty clumsy terminals that take longer than 30s to enter the token |
| 17:55.52 | 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' |
| 17:56.36 | DocScrutinizer05 | and finally it's useful to mitigate damage done when trust into anelok time is occasionally unjistified maybe |
| 17:58.32 | 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!° |
| 17:59.08 | DocScrutinizer05 | the only 'rationale' to not show timestamp is a "this will confuse users", something that never panned out so far |
| 18:00.39 | DocScrutinizer05 | and particularly showing timestamp will _not_ stop anelok from "working for normal users" |
| 18:01.33 | DocScrutinizer05 | I also didn't argue for neglecting to keep accurate time in anelok |
| 18:02.54 | 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 |
| 18:05.40 | *** join/#qi-hardware doomlord (~textual@host217-42-162-151.range217-42.btcentralplus.com) |
| 18:07.23 | 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 |
| 18:10.00 | DocScrutinizer05 | just for good measure you should not only provide timestamp but also suggest users compare it to UTC when using anelok |
| 18:10.48 | DocScrutinizer05 | the way *how* or *if* they do is up to them then |
| 18:36.21 | DocScrutinizer05 | maybe you find the analogy to providing md5sum for downloads convincing |
| 18:37.03 | DocScrutinizer05 | sure you should try to get error free transmission of data, nevertheless you're supposed to check with md5sum |
| 18:39.25 | *** join/#qi-hardware doomlord (~textual@host217-42-162-151.range217-42.btcentralplus.com) |
| 18:54.07 | 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. |
| 18:54.42 | wpwrak | i know this is very retro. zeitgeist would dictate that you need at least a permanent connection to some cloud service ;-) |
| 18:54.59 | whitequark | you're designing in bluetooth, right? |
| 18:55.16 | whitequark | that would cover a massive amount of user devices, given how every laptop and every smartphone has one |
| 18:55.34 | whitequark | well, less than massive, if you restrict yourself to BLE only |
| 18:55.35 | whitequark | but still a lot |
| 19:09.29 | *** join/#qi-hardware sandeepkr_ (~sandeep@111.235.64.4) |
| 19:12.11 | *** join/#qi-hardware sandeepkr__ (~sandeep@111.235.64.4) |
| 19:16.11 | *** join/#qi-hardware sandeepkr (~sandeep@111.235.64.4) |
| 19:16.33 | 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 |
| 19:16.54 | *** join/#qi-hardware sandeepkr_ (~sandeep@111.235.64.4) |
| 19:19.04 | 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 |
| 19:19.53 | 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 |
| 19:21.55 | 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 |
| 19:22.36 | DocScrutinizer05 | or make that "during phonecall I completely forgot the time, thought it were just 2 minutes" |
| 19:23.29 | DocScrutinizer05 | honestly, what's wrong with displaying the timestamp of generation time together with the token? |
| 22:44.43 | *** join/#qi-hardware GonZo2000 (~GonZo@178.32.60.54) |
| 22:44.43 | *** join/#qi-hardware GonZo2000 (~GonZo@unaffiliated/gonzo2000) |
| 23:32.04 | *** join/#qi-hardware dandon (~dandon@88.151.75.149) |
){kind=link}