| 00:16.03 | *** join/#qi-hardware kanzure (~kanzure@bryan.fairlystable.org) |
| 00:18.38 | *** join/#qi-hardware kanzure (~kanzure@unaffiliated/kanzure) |
| 03:40.33 | *** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 04:54.57 | *** join/#qi-hardware doomlord (~textual@host217-42-162-151.range217-42.btcentralplus.com) |
| 04:56.21 | wpwrak | DocScrutinizer05: discussion of the time-keeping circuits: http://lists.en.qi-hardware.com/pipermail/discussion/2016-March/011020.html |
| 05:35.57 | *** join/#qi-hardware sb0 (~lekernel@123202036228.ctinets.com) |
| 08:07.05 | *** join/#qi-hardware doomlord (~textual@host217-42-162-151.range217-42.btcentralplus.com) |
| 08:10.24 | *** join/#qi-hardware wildlander (~wild@unaffiliated/wildlander) |
| 08:30.13 | *** join/#qi-hardware doomlord (~textual@host217-42-162-151.range217-42.btcentralplus.com) |
| 08:36.49 | *** join/#qi-hardware sandeepkr__ (~sandeep@111.235.64.4) |
| 11:41.36 | DocScrutinizer05 | k |
| 11:42.02 | DocScrutinizer05 | btw did you notice the similarities between the FET in 4 and an "ideal diode" |
| 11:42.45 | DocScrutinizer05 | ? |
| 11:43.17 | wpwrak | yes, there's a bit of that there |
| 11:49.10 | *** join/#qi-hardware doomlord (~textual@host217-42-162-151.range217-42.btcentralplus.com) |
| 11:49.10 | DocScrutinizer05 | I just wonder what's the ABSMAX for the sMCU |
| 11:49.30 | DocScrutinizer05 | particularly regarding voltage on any pin vs VCC |
| 11:51.52 | DocScrutinizer05 | my final design recommendation is: ADC/GPIO[1] - 3M3 - C1 - GND; [1] - schottky - VCC |
| 11:53.20 | DocScrutinizer05 | the leakage current on ADC/GPIO is basically negligible resp no problem to probe for, after power return |
| 11:53.57 | DocScrutinizer05 | simply charge again until C1 full, then switch to discharge and probe voltage |
| 11:55.51 | DocScrutinizer05 | the temperature and thus leakage of the chip won't change in the timespan from battery change aka discharge, over probing residual charge on C1 after power return, to probing leakage after fully charging C1 after residual charge probing |
| 12:03.32 | DocScrutinizer05 | for 1uA@3V3 leakage current you got an equiv Z of 3M3, what a coincidence ;-) |
| 12:04.44 | DocScrutinizer05 | so your ADC would still probe with a multiplier of 0.5, which is easy to determine after you charged C1 to VCC, *after* probing residual charge after batt swap |
| 12:06.19 | DocScrutinizer05 | and 0.5 "prescaler" also leaves still enough precision in ADC |
| 12:06.49 | DocScrutinizer05 | s/precision/resolution/ |
| 12:06.50 | qi-bot | DocScrutinizer05 meant: "and 0.5 "prescaler" also leaves still enough resolution in ADC" |
| 12:07.10 | DocScrutinizer05 | it's just one bit less |
| 12:09.11 | DocScrutinizer05 | you could even get quarter-bit or even 1/8 bit resolution by polling at high speed and determinin time for first 1digit decrement vs time between 1st and 2nd 1bit decrement |
| 12:10.50 | DocScrutinizer05 | you even can *completely* eliminate prescaler effects of GPIO leakage, by doing a PWM beween charge and discharge to keep C1 voltage steady |
| 12:11.33 | DocScrutinizer05 | your C1 voltage is exactly Vcc * PWM ratio |
| 12:13.47 | DocScrutinizer05 | how much better than this could any other design get? |
| 12:14.30 | *** join/#qi-hardware doomlord (~textual@host217-42-162-151.range217-42.btcentralplus.com) |
| 12:15.30 | DocScrutinizer05 | (and how much simpler, BOM wise and to evaluate) |
| 12:16.46 | DocScrutinizer05 | wpwrak: ^^^ |
| 12:21.27 | DocScrutinizer05 | ((*completely* eliminate)) not only prescaler effects but also any nonlinearities in ADC |
| 12:21.56 | DocScrutinizer05 | only thing you can't completely eliminate but only mitigate with PWM is ADC noise |
| 12:25.48 | *** join/#qi-hardware doomlord (~textual@host217-42-162-151.range217-42.btcentralplus.com) |
| 12:27.28 | DocScrutinizer05 | to be precise: s/Vcc/Vio/g |
| 12:29.27 | DocScrutinizer05 | even when Vcc doesn't rapidly drop to 0V, it's still a given that the whole circuit is in a quasi static state without any variables, after MCU stopped working. So it should be highly repeatable |
| 12:30.56 | DocScrutinizer05 | IOW discharge is still predictable (by calibration) |
| 12:31.15 | DocScrutinizer05 | factory side calibration |
| 12:31.24 | wpwrak | the ADC is 16 bit. so i can make many ADC effects (not quite all, e.g., not non-linearity) vanish into bits that hold no useful value anyway ;-) |
| 12:31.56 | DocScrutinizer05 | you do a test series discharge time vs capacitor voltage, create a tab and that should be good enough |
| 12:32.17 | wpwrak | (pre |
| 12:32.30 | DocScrutinizer05 | at least for precision in the sub-second range during 60s |
| 12:33.07 | wpwrak | dictable) dunno. there are elements that may develop their own life before i can fully "neutralize" them. e.g., the OLED. |
| 12:33.31 | DocScrutinizer05 | how long will that take? 1s, or less? |
| 12:33.50 | wpwrak | that's what i don't know :) |
| 12:34.12 | DocScrutinizer05 | no matter if 1s or less, the effect on timing is negligible |
| 12:34.27 | DocScrutinizer05 | definitely can't be larger than 1s of error |
| 12:34.46 | DocScrutinizer05 | same for glitches |
| 12:36.47 | DocScrutinizer05 | before trying to eliminate dirt effects, we need to consider if they matter at all |
| 12:37.22 | DocScrutinizer05 | otherwise the cure will be much worse than the disease |
| 12:40.53 | wpwrak | if system leakage is in the order of 5 uA and we have about 50 uF of caps on the rail, a drop by 1 V would take 10 s |
| 12:41.27 | DocScrutinizer05 | fine |
| 12:42.18 | DocScrutinizer05 | and what are the variables in all this? |
| 12:42.46 | DocScrutinizer05 | I mean, the variables you can't determine even at runtime |
| 12:42.58 | DocScrutinizer05 | or even control at runtime |
| 12:43.06 | wpwrak | the MCU loses sight of things around 1.71 V, realistically much earlier, since we want to clean up and close shop as soon as we go significantly below 3.3 V |
| 12:43.19 | DocScrutinizer05 | fine |
| 12:43.35 | DocScrutinizer05 | then system is in a very well defined state from that moment |
| 12:43.54 | DocScrutinizer05 | the only vatiable I see is temperature |
| 12:44.44 | wpwrak | component variations, component state. e.g., the OLED has its own DC-DC converter that can keep things alive for a while |
| 12:45.05 | DocScrutinizer05 | so what? those won't change over lifetime of a particular device much |
| 12:45.36 | DocScrutinizer05 | you control component state |
| 12:46.01 | DocScrutinizer05 | that's the whole purpose of "closing shop" |
| 12:47.28 | DocScrutinizer05 | if factory side (R&D) calibration isn't sufficient, user needs to do a onetime calibration for the device (if you don't want to do this at factory for each device) |
| 12:47.30 | wpwrak | not necessarily. e.g., i don't really know what's going on inside the OLED, and i eventually lose the ability to communicate with it. i can still command a reset, though, but i don't know how that affects residual charges and the things they drive |
| 12:48.17 | DocScrutinizer05 | you can however instruct the display to switch on or off all pixels, as long as shop not closed yet |
| 12:48.51 | wpwrak | mmh. lemme check ... |
| 12:48.56 | DocScrutinizer05 | which I am pretty sure has identical effect on component state on all the OLEDs you ship |
| 12:50.24 | DocScrutinizer05 | there's no HRNG in OLED that creates massive uncertainties in component behavior |
| 12:51.40 | DocScrutinizer05 | when one OLED acts in a particular way once, it will do twice under same (history of) conditions, and other identical OLED components will as well |
| 12:52.41 | wpwrak | there is a "quick" display off command. in fact, there are two, with not very clearly spelled out differences |
| 12:52.42 | DocScrutinizer05 | if there are massive fluctuations between components of same bin, you need per-device calibration to cope with those |
| 12:53.29 | DocScrutinizer05 | otherwise one time R&D 'calibration' will do |
| 12:55.13 | DocScrutinizer05 | tbh I'd rather power on all consumers to pull Vcc to GND as fast as possible |
| 12:55.19 | wpwrak | of course, the more we clean up, the lower the leakage. so we're increasing that slope |
| 12:55.25 | wpwrak | yes, exactly ;-) |
| 12:55.54 | wpwrak | have some 100 uF anti-charge cap somewhere ;-) |
| 12:58.15 | DocScrutinizer05 | there are a number of nonlinear components like PTCs ;-) But honestly I'd not worry too much about all this, I'm pretty sure you can pull Vcc to GND in less than a second |
| 12:58.37 | DocScrutinizer05 | or at least to a steady state of maybe 1V5 above GND |
| 12:59.02 | DocScrutinizer05 | and you can do this very reproducibly |
| 12:59.49 | DocScrutinizer05 | irrespective of any random effects based on history of the component behavior (aka commands issued before) |
| 13:00.53 | DocScrutinizer05 | as I said, there's no HRNG in any of your components that would have massive impact on their behavior on power down |
| 13:01.20 | DocScrutinizer05 | only variable is temperature, yet to get evaluated if it matters at all |
| 13:04.33 | wpwrak | you don't need a HRNG. it's enough if there is something that can be in different internal states you don't control. that's what i'm worried about. |
| 13:04.35 | DocScrutinizer05 | particularly system behavior from 1V5 down to 0V on Vcc is pretty reproducible |
| 13:04.54 | wpwrak | and i can't actually test such things before having a number of devices |
| 13:05.33 | DocScrutinizer05 | you hardly have *any* devices with different internal stages after receiving same sequence of commands |
| 13:05.42 | wpwrak | hence i prefer a "safe" design that itsn't at risk of needing a redesign at that point |
| 13:06.44 | DocScrutinizer05 | you don't need several devices, random different internal stages are a problem of *one* device |
| 13:07.16 | wpwrak | i don't really have time for elaborate transitions. e.g., the OLED has transitions that are specified to take some 100 ms. i can't risk waiting for such things. |
| 13:07.42 | DocScrutinizer05 | which you can test right away. and designing for a 100% safe circuit no matter which possible nasty properties components might have is not possible |
| 13:08.32 | DocScrutinizer05 | huh? don't you know in which state the OLED is, before as well as after such transition? |
| 13:08.41 | DocScrutinizer05 | isn't that deterministic? |
| 13:08.59 | wpwrak | (test right away) naw, there are several new components in the new design for which no prototype exists yet |
| 13:09.33 | DocScrutinizer05 | I just can tell you you're massively overengineering this |
| 13:10.00 | DocScrutinizer05 | if time is SOOOOO important, add a cmos clock and a goldcap |
| 13:10.00 | wpwrak | i know the "high-level" state before and i know the state after. what happens in the middle, duh. inside the high-level state, there are internal sub-states that are hidden from me. |
| 13:10.07 | wpwrak | heh ;-) |
| 13:12.28 | wpwrak | may not be so difficult to be able to support page 3 (diode) and page 4 (fet) design in the same circuit, with a minor placement change |
| 13:13.31 | DocScrutinizer05 | both add more complications than they solve |
| 13:13.48 | wpwrak | so you don't like the diode anymore ? |
| 13:14.10 | DocScrutinizer05 | my final design recommendation is: ADC/GPIO[1] - 3M3 - C1 - GND; [1] - schottky - VCC |
| 13:15.10 | wpwrak | page 3 is pretty much that, except that i add a lower R between C1 and ADC/GPIO |
| 13:15.22 | DocScrutinizer05 | [2016-03-27 Sun 13:49:10] <DocScrutinizer05> I just wonder what's the ABSMAX for the sMCU - particularly regarding voltage on any pin vs VCC (when Vcc = 0V and capacitor 3V) |
| 13:16.11 | DocScrutinizer05 | and no, your design is massively different in that respect to mine |
| 13:16.23 | wpwrak | okay, that's a fair point |
| 13:17.29 | wpwrak | the absmax is the usual vdd + 0.3 V but there is no clamping diode. so i don't quite know what happens. |
| 13:18.29 | DocScrutinizer05 | @ occasional lurkes: Vdd is another synonymous name for Vcc |
| 13:18.30 | wpwrak | what really worries me in your design is the huge resistance amplifying even the tiniest GPIO leakage |
| 13:20.08 | wpwrak | well, i guess i could always raise C1 to 47 uF or such :) |
| 13:20.17 | DocScrutinizer05 | as I elaborated you got the precision of a 1bit delta-slope converter ( precision of your timebase) for ADC when you do that PWM pattern I suggested. Completely irrespective of any leahage current however large or small |
| 13:21.52 | DocScrutinizer05 | well, actually the precision limit is the noise and resolution of the ADC, but *not* any prescaler formed by resistors and leakage current |
| 13:23.33 | DocScrutinizer05 | when you switch 8PWM) between 25% charging via R from Vcc and 75% discharging via R to GND and that keeps your voltage staedy, then you know your capacitor has exactly 25% of Vcc resp Vio |
| 13:23.45 | DocScrutinizer05 | s/8/(/ |
| 13:23.46 | qi-bot | DocScrutinizer05 meant: "when you switch (PWM) between 25% charging via R from Vcc and 75% discharging via R to GND and that keeps your voltage staedy, then you know your capacitor has exactly 25% of Vcc resp Vio" |
| 13:24.18 | wpwrak | i don't see how PWM would help with measuring. charging/discharging is not a problem, since we have low impedance anyway |
| 13:24.28 | DocScrutinizer05 | see above |
| 13:24.51 | DocScrutinizer05 | my final design recommendation is: ADC/GPIO[1] - 3M3 - C1 - GND; [1] - schottky - VCC |
| 13:25.27 | DocScrutinizer05 | 3 components, one GPIO |
| 13:26.13 | DocScrutinizer05 | capacitor voltage probable to 0.1% precision almost irrespective to size of R |
| 13:27.00 | DocScrutinizer05 | no overvoltage issues at GPIO (when Vdd = 0V). Immune tio glitches |
| 13:28.19 | DocScrutinizer05 | yes, it still has the 'problem' of Vdd not falling to 0V for 20s, but we discussed that thoroughly during last 30min, it can get taken care of by software design |
| 13:28.57 | DocScrutinizer05 | by fast discharge as well as R&D or factory (per unit) calibration |
| 13:30.17 | DocScrutinizer05 | one particular OLED won't suddently start to behave randomly differnet, when you propperly "initialize" it during shutdown |
| 13:31.17 | DocScrutinizer05 | when there are N different states the component can be in, and you can't transition fast between them, all you need to do is to know the current state and apply the according calibration |
| 13:31.45 | DocScrutinizer05 | there is no HRNG |
| 13:32.04 | DocScrutinizer05 | your circuit is mostly deterministic |
| 13:33.24 | wpwrak | (see above) hmm, that would help with the part of the error that is because of component variation. i wouldn't help with error due to chip temperature. i wonder if we can do such precise temperature compensation. after all, the possible V difference would be basically the whole measurement range, with the leakage current going through 3.3 MOhm. |
| 13:33.30 | DocScrutinizer05 | you know the state it's in so you can predict how it behaves |
| 13:33.59 | DocScrutinizer05 | you still didn't grok the PWM thing? |
| 13:34.45 | wpwrak | i think i get the PWM thing: you charge to a well-known voltage, then measure, and thus calculate the leakage current |
| 13:35.10 | DocScrutinizer05 | when you switch (PWM) between 25% charging via R from Vcc and 75% discharging via R to GND and that keeps your voltage staedy, then you know your capacitor has exactly 25% of Vcc resp Vio - capacitor voltage probable to 0.1% precision almost irrespective to size of R and leakage current |
| 13:35.20 | DocScrutinizer05 | no |
| 13:36.13 | DocScrutinizer05 | I do PWM charge/discharge to keep the ADC at a steady level that was the value when first probing the voltage of C1 |
| 13:36.25 | *** join/#qi-hardware sandeepkr__ (~sandeep@111.235.64.4) |
| 13:36.57 | DocScrutinizer05 | leakage current: irrelevant doesn't show up in equation |
| 13:37.29 | DocScrutinizer05 | same for size of R |
| 13:37.58 | wpwrak | how does a PWM with fixed ratio hold an arbitrary initial voltage ? |
| 13:38.24 | DocScrutinizer05 | PWM= 42.4711%, so voltage on C = Vio/Vcc * 42.4711% |
| 13:38.56 | wpwrak | sure. but how does this help with _measuring_ ? |
| 13:39.00 | DocScrutinizer05 | the trick is to adjust the PWM so it has same average voltage as C |
| 13:39.19 | *** join/#qi-hardware doomlord (~textual@host217-42-162-151.range217-42.btcentralplus.com) |
| 13:39.29 | wpwrak | you're talking about a second RC circuit, for the PWM ? |
| 13:39.40 | DocScrutinizer05 | no |
| 13:41.39 | DocScrutinizer05 | with a given capacitor voltage (to probe) of 42.4711%, you first get a ADC that results in value 12345, then you start with a PWM of 50% (you can optimize by guessing the needed PWM from 12345) and watch the ADC. It will go up to 12350 or whatever, so you know your 50% are too high and you turn it down to 45% |
| 13:42.11 | DocScrutinizer05 | redu until your ADC again shows 12345 and your PWM vill be 42.4711% |
| 13:42.19 | DocScrutinizer05 | redo even |
| 13:42.43 | wpwrak | ah, i see. so 2 (or more) measurements |
| 13:42.53 | DocScrutinizer05 | all percentages of voltage with respect to Vio/Vdd |
| 13:43.07 | DocScrutinizer05 | yes, multiple measurements |
| 13:43.37 | wpwrak | temperature may still be an issue. if the MCU is actively moving things around, that may change the chip temperature a little. and since we're extremely temperature-sensitive there, ... |
| 13:44.04 | wpwrak | but okay, that could probably be compensated, too |
| 13:44.11 | DocScrutinizer05 | the only variables determining precision are: the *relative* precision of ADC (noise and resolution), Vdd and your timer for PWM |
| 13:44.44 | wpwrak | e.g., meas(temp), meas(Vc1), meas(temp), then do the PWM routing, also all the while measuring the temperature |
| 13:45.51 | wpwrak | <PROTECTED> |
| 13:45.55 | DocScrutinizer05 | how much could temperature change during 2 minutes? also where is temperature realyl coming in here. For sure not for probing, probbaly for Vcc discharge though |
| 13:48.43 | wpwrak | sure for probing. don't forget that it can go up to 1 uA over a 100 C range. so that's about 1% of the measurement range for each C, assuming the change is linear |
| 13:49.01 | DocScrutinizer05 | hmm? |
| 13:49.24 | wpwrak | we'll be trying to measure differences < 1% of the range |
| 13:49.42 | DocScrutinizer05 | so? |
| 13:49.45 | wpwrak | range = [0, 3.3 V]. 1 uA * 3.3 MOhm = 3.3 V, 100% of the range |
| 13:50.09 | DocScrutinizer05 | you're confused :-) |
| 13:50.13 | wpwrak | so even slight temp changes can throw us off |
| 13:50.32 | DocScrutinizer05 | no, leakage current doesn't show up in the equation |
| 13:50.51 | wpwrak | max leakage is 25 nA at 25 C and 1 uA "over full temp range", i.e., at 125 C |
| 13:50.58 | DocScrutinizer05 | this "meter" is completely immune to leakage current |
| 13:51.13 | wpwrak | but only if you're assuming constant leakage |
| 13:51.18 | DocScrutinizer05 | yes |
| 13:51.22 | wpwrak | what i'm saying is that it changes |
| 13:51.24 | DocScrutinizer05 | during measuring period |
| 13:51.31 | DocScrutinizer05 | which is <1s |
| 13:52.00 | DocScrutinizer05 | I don't see how temperature could change during this period of time |
| 13:54.44 | DocScrutinizer05 | maybe it helps ro check wikipedia for sigma-delta ADC |
| 13:55.00 | wpwrak | hmm, i get about 0.7 C, assuming we draw ~2 mA on average. that would be okay. |
| 13:56.16 | DocScrutinizer05 | this is a modified sigma-delta scheme |
| 13:57.27 | wpwrak | i understand the process, my concern is the effect of leakage changing during the process. but it seems that the change would be relatively small. |
| 13:57.44 | DocScrutinizer05 | https://en.wikipedia.org/wiki/File:Fig._1b.svg |
| 13:59.23 | DocScrutinizer05 | you can bet on the effect being too small to calculate it without help of an electronic calculator ;-) |
| 14:00.42 | DocScrutinizer05 | it will be serveral magnitudes lower than your demanded precision of 1% |
| 14:01.07 | DocScrutinizer05 | _several_ |
| 14:06.49 | wpwrak | i get about 1 C = 1%, so, zero magnitudes :) still, that's already |
| 14:08.21 | DocScrutinizer05 | how's the chance for the low power chip to heat up 1°C during less than 1s, in a semi-steady state 2 or 3 seconds after power up |
| 14:09.39 | DocScrutinizer05 | your stability of Vdd is a more concerning issue regarding ADC precision |
| 14:10.14 | DocScrutinizer05 | after all we use Vdd as reference voltage here, all the time |
| 14:12.43 | DocScrutinizer05 | dunno if your ADC has an internal stabilized refernce voltage so you could use ADC to determine actual voltage of Vio |
| 14:13.56 | wpwrak | Vcc should be pretty stable, and when we ramp down, we already assume we fall rapidly, right ? :) i'd set the low voltage interrupt close to 3.3 V, so te MCU reacts within some 10% of the range. |
| 14:14.08 | wpwrak | and yes, the ADC has a bandgap reference, too |
| 14:14.25 | wpwrak | they pretty much all do nowadays ;-) |
| 14:15.12 | DocScrutinizer05 | so you can probe the real voltage during charging, while same time pulling ADC/GPIO high and probing it |
| 14:15.57 | DocScrutinizer05 | and you also can probe the real low voltage on ADC/GPIO = L |
| 14:17.15 | DocScrutinizer05 | now you have a very precise Vhigh and Vlow and a very precise PWM timing, you're set |
| 14:20.11 | DocScrutinizer05 | your capacitor voltage is Vlow + PWM% * (Vhigh - VLOW) |
| 14:20.30 | DocScrutinizer05 | which for 100% PWM = Vhigh ;-) |
| 14:20.41 | DocScrutinizer05 | aka charging |
| 14:23.58 | wpwrak | Vlow (i.e., ADC = 0 V) will be close enough to GND, even if we go for the full 16 bit resolution :) 1 uA * 100 Ohm ~ 2 * 3.3 V >> 16 ;-) |
| 14:24.16 | wpwrak | (10 or 12 bit probably makes more sense) |
| 14:25.02 | DocScrutinizer05 | well, you have a load current through discharging, via the 3M3, so your Vlow might be higher than 0V00 |
| 14:25.42 | wpwrak | yes, by up to 3.3 V / 3.3 MOhm = 1 uA :) |
| 14:25.54 | DocScrutinizer05 | actually it depends on Vcapacitor too |
| 14:26.00 | DocScrutinizer05 | aaah ok |
| 14:26.04 | DocScrutinizer05 | yes, right |
| 14:44.38 | DocScrutinizer05 | Vcc stability during ramp-down is no problem, after all you're either in charging mode and the slight variation in Vcc will be less than a glitch for this circuit, or you already entered discharging mode where Vcc doesn't matter at all |
| 14:46.31 | DocScrutinizer05 | we also have one 'problem' with this circuit: charging takes as long as discharging, so the recovery window after power return is rather long. No two battery swaps in sequence |
| 14:47.06 | DocScrutinizer05 | well, can get mitigated in software |
| 14:49.33 | DocScrutinizer05 | actually you just need to write history (with timestamps) to storage, to have the complete picture and do the "right thing" |
| 14:51.11 | DocScrutinizer05 | histroy can get deleted as soon as capacitor is supposedly recharged to 100% after a few minutes of charging time |
| 16:50.28 | *** join/#qi-hardware sb0 (~lekernel@123202036228.ctinets.com) |
| 17:01.55 | *** join/#qi-hardware fdcx (357@ceata/consiliu/FDCX) |
| 18:20.16 | dcht00 | *************** Announce :) |
| 18:20.21 | dcht00 | New CHT hackbase subseason CHT4-D, MAY/JUNE 2016 @ http://next.totalism.org |
| 18:20.31 | dcht00 | Would be awesome if some of you guys make it |
| 18:20.42 | *** join/#qi-hardware sandeepkr_ (~sandeep@111.235.64.4) |
| 19:15.26 | DocScrutinizer05 | would love to, but seems too much of a dealbraker for my ordinary daywork tasks |
| 19:20.36 | whitequark | dcht00: what the hell is that event anyway? |
| 19:20.42 | whitequark | I don't get it |
| 19:21.58 | dcht00 | did you try to read from "Start here" ? |
| 19:22.18 | whitequark | ohhh |
| 19:22.22 | whitequark | nope |
| 19:23.29 | whitequark | dcht00: wow that's really interesting |
| 19:24.13 | dcht00 | whitequark thanks - refresh site, i tried to make Context stand out more |
| 19:24.39 | whitequark | dcht00: hmmmm i would be interetsted to at least visit |
| 19:24.44 | whitequark | a few days? |
| 19:24.45 | dcht00 | it's basically hacking in wild canary islands nature ....... on stuff that makes you not die / more comfortable :) |
| 19:25.24 | dcht00 | awesome, all info you need should be on the pad, pls let me know if anything else is unclear |
| 19:30.53 | whitequark | dcht00: visa info? I need spanish visa, right? |
| 19:31.12 | dcht00 | whitequark where are you based / nationality? |
| 19:31.20 | whitequark | russian |
| 19:31.30 | whitequark | live in hong kong though |
| 19:31.40 | whitequark | holy shit the tickets are worth a small fortune |
| 19:31.44 | dcht00 | oh, i have no clue tbh ... i think russians do need a visa for Spain, yeah ... sorry about that |
| 19:32.20 | dcht00 | the whole idea is to have it in Canary Islands which is very cheap and easy to come for EU people |
| 19:32.33 | dcht00 | Hong Kong is quite a stretch |
| 19:32.45 | whitequark | $1827 and 44 hours one way |
| 19:32.53 | dcht00 | you'd probably make it easier to Hillhacks in India ....... check http://totalism.org/calendar |
| 19:32.59 | dcht00 | another awesome event |
| 19:33.13 | whitequark | .... I'll pass, a 44 hour flight is too much of a torture itself to pay that much for it lol |
| 19:39.47 | DocScrutinizer05 | 44h honestly? |
| 19:40.01 | DocScrutinizer05 | I had a 12h to Teipei from Germany |
| 19:40.24 | DocScrutinizer05 | ok I had a 14h trip from germany to Gomera |
| 19:40.43 | DocScrutinizer05 | this still makes no more than 28h even from HK |
| 19:41.37 | DocScrutinizer05 | also the trip Germany - TPE was a 800EUR iirc |
| 19:41.58 | DocScrutinizer05 | Germany - Gomera was 300 |
| 19:42.13 | DocScrutinizer05 | twoway |
| 19:43.05 | DocScrutinizer05 | hmm, TPE- Germany twoway might actually be USD 1800 then |
| 19:43.46 | DocScrutinizer05 | anyway, recheck, it sounds like you didn't find the best offer / flight yet |
| 19:47.28 | DocScrutinizer05 | dcht00: I studied the CHT website a few months ago already, thus I knew what it's all about |
| 19:47.31 | DocScrutinizer05 | :-) |
| 19:47.38 | DocScrutinizer05 | kudos |
| 20:34.16 | whitequark | DocScrutinizer05: the others are even more stupidly epxensive and not much shorter |
| 20:39.31 | wpwrak | DocScrutinizer05: how do you like this one ? https://defuse.ca/b/Get2nVONkfdFVqQaFEkHQc |
| 20:49.22 | wpwrak | whitequark: a wild search HKG-LPA, suggests ~USD 1k (in argentina) with 25h10 + 20h15, with KLM and AF. may 5, june 1. (since this seems to be a month-long event ?) |
| 20:51.06 | wpwrak | then you just need a boat to make it to lanzarote :) |
| 20:54.20 | whitequark | hm, then my search engine fucked up |
| 21:01.11 | DocScrutinizer05 | wpwrak: I'm fixing the code |
| 21:02.42 | DocScrutinizer05 | rather, the algo, I'm prolly fscking up the code ;-) |
| 21:04.11 | wpwrak | whitequark: maybe don't search from your iphone ;-) |
| 21:04.31 | dcht00 | DocScrutinizer05 good to see we have friends everywhere :) |
| 21:04.40 | dcht00 | if you send an email saying hi at a random time that'd make my day |
| 21:05.20 | whitequark | wpwrak: I don't have an iphone, nor did I search from a smartphone... |
| 21:06.15 | wpwrak | whitequark: hehe ;) i was referring to iphone users sometimes getting shown more expensive offers than the rest of humanity |
| 21:06.59 | dcht00 | quick search from me: |
| 21:07.33 | dcht00 | 12h + 1200⬠to go from Hong Kong to Germany |
| 21:07.39 | whitequark | ahhhh, I had no idea |
| 21:07.53 | wpwrak | DocScrutinizer05: (algo) i used a simple one to illustrate the concept. in real life, there would be more non-linear components, but factoring them in would just make it harder to see the basic idea |
| 21:07.56 | dcht00 | from there it's another 5h to Lanzarote, with some layover |
| 21:08.14 | DocScrutinizer05 | the basic idea needs fixing |
| 21:08.18 | dcht00 | but ....... I honestly wouldn't encourage you to spend 3 grand to travel here :) |
| 21:08.35 | dcht00 | donations of 1% of that are very welcome though |
| 21:08.39 | dcht00 | :) |
| 21:13.23 | wpwrak | whitequark: it's lanzarote that makes it expensive. to las palmas it's about 1/2 of hkg-lanzarote |
| 21:14.22 | whitequark | mhrm |
| 21:14.33 | wpwrak | (didn't try to vary dates. maybe that would change it, too) |
| 21:22.59 | wpwrak | but it;s probably best to fly to gran canaria, then make the last hop with a local LCC, or maybe a ferry if that's common there. the local organizers should know |
| 21:23.34 | wpwrak | the usual travel sites sometimes don't even list the LCCs, so you miss the most efficient routes |
| 21:25.40 | DocScrutinizer05 | wpwrak: http://paste.opensuse.org/86669840 |
| 21:26.46 | DocScrutinizer05 | err linwe 19 is wrong |
| 21:27.26 | DocScrutinizer05 | duty = ADC_RANGE / adc_0 * 100 |
| 21:28.02 | wpwrak | btw, argentina just grew some 1.7 million km^2 ;-) http://buenosairesherald.com/article/211476/foreign-ministry-to-unveil-argentinas-continental-shelf-limits-on-monday- |
| 21:30.43 | DocScrutinizer05 | wpwrak: this code is still full of bugs and mess, but it demonstrates the idea |
| 21:30.52 | wpwrak | no "* 100%" in c-ish syntax ;-) |
| 21:31.19 | DocScrutinizer05 | huh? |
| 21:32.28 | wpwrak | that's very slow convergence. mine tries to converge much faster. that's especially imporant considering that also PWM goes through 3.3 V, so it may take a lot of time to change Vc1. |
| 21:32.56 | DocScrutinizer05 | ??? |
| 21:33.28 | DocScrutinizer05 | yours doesn't converge any way, it's a one time calculation that tries to figure leakage current |
| 21:33.38 | *** join/#qi-hardware dandon (~dandon@88.151.75.149) |
| 21:33.44 | wpwrak | anyway, in think the main idea is to adjust C1 through PWM and then measure what we got. whether we then operate with deltas or stepwise approximation, is a second order problem |
| 21:34.37 | DocScrutinizer05 | no, the idea is to NOT adjust C1 and keep it at a given ADC value instead. Finmd the PWM duty that matches this condition |
| 21:35.24 | wpwrak | well, a bit like euler's method :) |
| 21:35.40 | DocScrutinizer05 | a bit like sigma-delta ADC |
| 21:35.56 | wpwrak | but you do adjust C1 |
| 21:35.59 | DocScrutinizer05 | delta-sigma? |
| 21:36.48 | DocScrutinizer05 | only temporarily until it changes one tick on ADC so I know if PWM is too high or too low. Then I immediately resore it to its original voltage |
| 21:37.20 | DocScrutinizer05 | actually NOISE_THRESHOLD = 2 ticks |
| 21:38.39 | DocScrutinizer05 | C1's voltage is meant to keep constant (+-2 ticks) during complete PWM-ADC |
| 21:39.31 | DocScrutinizer05 | while PWM gets adjusted so it keeps C1 voltage at that ADC level for long time (NUM_SAMPLES = 20) |
| 21:39.48 | DocScrutinizer05 | you can make NUM_SAMPLES = 2000 if you like |
| 21:43.19 | DocScrutinizer05 | ooh, and that code for sure is no C syntax, rather a tad pythony |
| 21:47.48 | DocScrutinizer05 | only temporarily until it changes one tick on ADC <(abs(adc_t - adc_0) > NOISE_THRESHOLD) ; line25> so I know if PWM is too high or too low <(adc_t - adc_0) >0; line28> |
| 21:48.52 | DocScrutinizer05 | Then I immediately restore it to its original voltage <lines 29-32, 34-37> |
| 21:49.59 | DocScrutinizer05 | lines 31, 36 are >> // adjust duty TODO: short hack, optimize!<< and actually need optimization |
| 21:50.18 | DocScrutinizer05 | there Euler comes in |
| 21:50.49 | DocScrutinizer05 | N +- N/2 +- N/4... |
| 21:51.49 | wpwrak | those duty++ and duty-- should be outside the loops, right ? |
| 21:51.55 | DocScrutinizer05 | no |
| 21:52.37 | DocScrutinizer05 | not really, I kept them inside the loops since duty needs the more adjustment the longer recovery takes |
| 21:52.55 | DocScrutinizer05 | might overshoot though |
| 21:53.29 | DocScrutinizer05 | you could keep them outside the loops too |
| 21:54.16 | DocScrutinizer05 | but ideally you find some sort of Euler, based on i counter in 22-25 |
| 21:54.57 | DocScrutinizer05 | the 22-25 loop will iterate the longer, the closer duty is to the target |
| 21:55.24 | DocScrutinizer05 | so for higher i, the duty adjustment should be lower |
| 21:56.06 | DocScrutinizer05 | duty++ and -- are really just meant symbolic |
| 21:57.06 | wpwrak | yeah, you'd probably want some t++ and then duty += f(t) or such |
| 21:57.11 | DocScrutinizer05 | ((will iterate the longer...)) when it iterates > NUM_SAMPLES times, duty is considered perfect |
| 21:57.23 | DocScrutinizer05 | yes |
| 21:57.32 | DocScrutinizer05 | oops is it t? |
| 21:57.49 | DocScrutinizer05 | no it's i, line 21 |
| 21:57.50 | wpwrak | t for the time you "correct" |
| 21:57.59 | wpwrak | a new variable |
| 21:58.09 | DocScrutinizer05 | DANG!!! |
| 21:58.29 | DocScrutinizer05 | 25: until ((i++ > NUM_SAMPLES) or (abs(adc_t - adc_0) > NOISE_THRESHOLD)) |
| 21:58.52 | wpwrak | since duty is measured in adc counts, while the correction loops count in loop counts |
| 21:59.04 | wpwrak | (i++) hehe :) |
| 21:59.13 | DocScrutinizer05 | duty is measured in percent |
| 21:59.29 | DocScrutinizer05 | line 6 |
| 21:59.51 | wpwrak | i just used a float ;-) |
| 21:59.57 | DocScrutinizer05 | you prolly want to make that ppm |
| 22:00.32 | wpwrak | polly some obscure implementation-dependent unit :) |
| 22:00.54 | DocScrutinizer05 | nah, it's a plain simple integer, see line6 |
| 22:01.11 | DocScrutinizer05 | and line3 |
| 22:02.02 | DocScrutinizer05 | make line6 usleep(100000 - pw) or whatever you like |
| 22:02.20 | DocScrutinizer05 | it determines range of duty and frequency of PWM |
| 22:02.53 | wpwrak | sure, in the end it's an integer. everything is :) |
| 22:03.20 | DocScrutinizer05 | this one reasonably is a 12 to 16bit integrer, unsigned |
| 22:04.11 | DocScrutinizer05 | it doesn't make sense to have it higher precision than your ADC can do and actually does |
| 22:05.59 | DocScrutinizer05 | you also can't feed a real to usleep |
| 22:08.12 | wpwrak | i have my own timekeeping anyway. well, i do happen to have a function called usleep ... |
| 22:11.28 | DocScrutinizer05 | http://paste.opensuse.org/94860912 |
| 22:17.38 | DocScrutinizer05 | http://paste.opensuse.org/80816228 even |
| 22:18.41 | DocScrutinizer05 | usleep(MAXPWM) is the frequency (actually period) of your PWM signal |
| 22:20.09 | DocScrutinizer05 | if you need higher resolution (higher MAXPWM) and same time higher PWM frequency, you should divide all parameters to usleep() by a constant factor |
| 22:27.07 | *** join/#qi-hardware MistahDarcy (~crash@fsf/member/MistahDarcy) |
| 22:27.09 | DocScrutinizer05 | one more bug smashed: http://paste.opensuse.org/20517572 |
| 22:27.47 | DocScrutinizer05 | now I actually should add (C) GPL2 J.R. to this |
| 22:28.17 | DocScrutinizer05 | the shorter the code, the better ;-) |
| 22:32.27 | DocScrutinizer05 | OHMY |
| 22:33.23 | DocScrutinizer05 | s/ (adc_t - adc_0) >0) / (adc_t > adc_0) / |
| 22:34.35 | DocScrutinizer05 | wpwrak: ^^^ |
| 22:36.32 | wpwrak | yeah :) |
| 22:36.40 | wpwrak | i just c-ified it |
| 22:36.52 | DocScrutinizer05 | highly welcome |
| 22:37.09 | DocScrutinizer05 | it's crap, syntax wise |
| 22:37.31 | wpwrak | https://defuse.ca/b/0iPMvsYL0SlBmXqeRyxtC6 |
| 22:37.45 | DocScrutinizer05 | heck, I wrote my last c code some maybe 6 years ago |
| 22:38.55 | wpwrak | mmh. two small bugs |
| 22:39.28 | DocScrutinizer05 | <PROTECTED> |
| 22:39.53 | DocScrutinizer05 | well, maybe it's actually correct, however puzzling# |
| 22:41.21 | wpwrak | add "Vadc =" ? |
| 22:41.37 | wpwrak | or what is the puzzling bit ? |
| 22:43.41 | DocScrutinizer05 | the equation is puzzling me |
| 22:44.01 | DocScrutinizer05 | yes, it's actually correct |
| 22:44.27 | DocScrutinizer05 | I'd write "sample relative Vc1" |
| 22:44.32 | DocScrutinizer05 | stop |
| 22:44.55 | wpwrak | making it sample Vadc = Vc1 + Ileak(t0) * R1 |
| 22:45.01 | DocScrutinizer05 | it's a tad out of scope how Ileak calculates Vadc here |
| 22:45.05 | wpwrak | else i need to define what a "relative Vc1" is |
| 22:45.22 | DocScrutinizer05 | now you need to define what Ileak is ;-) |
| 22:45.35 | wpwrak | oh, didn't i talk enough about leakage current before ? :) |
| 22:45.45 | DocScrutinizer05 | here yes ;-D |
| 22:45.51 | DocScrutinizer05 | lol |
| 22:45.55 | wpwrak | in the mail, too ;-) |
| 22:45.59 | DocScrutinizer05 | aah ok |
| 22:46.03 | DocScrutinizer05 | well nevermind |
| 22:46.12 | DocScrutinizer05 | I'm ore worried about INCREMENT |
| 22:46.31 | DocScrutinizer05 | and heck, another bug |
| 22:48.02 | DocScrutinizer05 | http://paste.opensuse.org/58706276 fixed |
| 22:48.18 | DocScrutinizer05 | (took the pwm adj out of the loop) |
| 22:48.53 | wpwrak | posted: http://lists.en.qi-hardware.com/pipermail/discussion/2016-March/011021.html |
| 22:49.00 | DocScrutinizer05 | you also might actually want to probe for (and use) V3_3 instead of using a constant |
| 22:49.33 | DocScrutinizer05 | line6 |
| 22:49.54 | DocScrutinizer05 | and line30 |
| 22:50.13 | DocScrutinizer05 | the rest looks good to me |
| 22:51.07 | wpwrak | it's not real code. 3.3 is just 3.3 V :) |
| 22:51.43 | DocScrutinizer05 | s/do pulse(100);/do pulse(1.0);/ |
| 22:52.09 | DocScrutinizer05 | yes, but 3.3V is not warranted |
| 22:52.24 | DocScrutinizer05 | this is actually Vio_h |
| 22:52.31 | wpwrak | yes, fixed in the post |
| 22:53.15 | wpwrak | sure. but Vio_h(I very tiny) is Vcc is 3.3 V |
| 22:53.20 | wpwrak | else something is broken :) |
| 22:53.33 | DocScrutinizer05 | for me INCREMENT is (NUM_SAMPLES - i) |
| 22:54.13 | DocScrutinizer05 | for you it's SAMPLES - i |
| 22:54.26 | DocScrutinizer05 | err |
| 22:54.53 | DocScrutinizer05 | SAMPLES/i ? |
| 22:55.30 | DocScrutinizer05 | a real 0<=duty<=1 is really messy to handle |
| 22:55.36 | wpwrak | i think one would want to calculate the quanta that went into or out of C1 |
| 22:56.22 | DocScrutinizer05 | duty +- i/SAMPLES, now that looks correct |
| 22:57.27 | wpwrak | probably more complicated. but i'm too lazy to do the math now :) |
| 22:57.37 | DocScrutinizer05 | me too ;-) |
| 22:58.22 | wpwrak | and with a little luck there may be a simple direct temperature correction that works just as well, and we don't need all this ;-) |
| 23:00.06 | DocScrutinizer05 | <PROTECTED> |
| 23:01.04 | wpwrak | something like Ileak = 25 nA * max(1, tempC - 25) * (3.3 / 2 - real_Vc1); // or such |
| 23:01.53 | wpwrak | it's already posted :) let's see if anyone has questions |
| 23:02.25 | DocScrutinizer05 | s/ For faster convergence, INCREMENT should be a function of the time it took to pull Vc1 back to the original value./ For faster convergence, INCREMENT should be a function of the time it took to pull Vc1 AWAY FROM THE original value./ |
| 23:03.32 | wpwrak | that may be easier, indeed. i was thinking of some f(t, duty) |
| 23:03.53 | DocScrutinizer05 | http://paste.opensuse.org/58706276 |
| 23:03.56 | wpwrak | but again, one would have to do the math. not sure if duty really disappears if you use i |
| 23:04.19 | DocScrutinizer05 | sorry? |
| 23:04.37 | DocScrutinizer05 | lost me on the second half |
| 23:05.25 | wpwrak | i'm not sure if it's just a function of "i", or if it would still be a function of i and "duty" |
| 23:05.25 | DocScrutinizer05 | duty += i/SAMPLES |
| 23:05.30 | DocScrutinizer05 | resp -= |
| 23:06.18 | wpwrak | as i said, too lazy to do the math :) |
| 23:06.18 | DocScrutinizer05 | s$ INCREMENT $ i/SAMPLES $ |
| 23:07.26 | DocScrutinizer05 | s$ INCREMENT $ (i/SAMPLES / 4) $ |
| 23:07.55 | DocScrutinizer05 | or whatever factor works best |
| 23:08.28 | DocScrutinizer05 | it's just an optimization, you can spend weeks to optimize the optimization, or just go 'Meh!' |
| 23:08.56 | DocScrutinizer05 | it just should converge |
| 23:09.23 | DocScrutinizer05 | too high feedback and you get oscillation |
| 23:16.50 | DocScrutinizer05 | anyway, time to search the eggs ;-) |
| 23:34.12 | wpwrak | (oscillation) yes, and the thing needs some more timeouts anyway, right now, it could easily loop somewhere forever |
| 23:58.34 | *** join/#qi-hardware arossdotme (~zxy@host-78-151-194-28.as13285.net) |
