| 00:00.21 | wpwrak | nicksydney: their marketing is good :) |
| 00:23.48 | DocScrutinizer05 | wpwrak: please check helptext and the interface semantics |
| 00:23.50 | DocScrutinizer05 | http://paste.opensuse.org/34737169 |
| 00:31.29 | *** join/#qi-hardware xiangfu (~xiangfu@123.125.212.79) |
| 00:37.50 | DocScrutinizer05 | actually http://paste.opensuse.org/62559743 |
| 00:44.18 | wpwrak | 2nd invocation variant seems to be redundant. you could just say that "-c <int>" defaults to 1. |
| 00:45.41 | wpwrak | "dateformat of timestamp right to result" doesn't parse. did you mean "right next" ? |
| 00:46.40 | wpwrak | also, i wouldn't mention variable names at the beginning of each description. why not do it the other way around and mention the relation between options and variables in comments in the code ? |
| 00:47.14 | wpwrak | "(1)date +format" looks confusing. better to just omit the "(1)" |
| 00:48.51 | wpwrak | "separator/delimiter in between" no "in". "in between" is like "dazwischen" |
| 00:49.13 | wpwrak | "May occcur multi" ... and then joerg fell asleep ;-) |
| 00:50.12 | wpwrak | -E seems a little odd. if there's an error, i would by default fail clearly, not try to print whatever result may be there |
| 00:50.28 | wpwrak | "index0" space missing ? |
| 00:52.09 | wpwrak | "an ENV var u1233" you have a lot of abbreviations and command examples in that line. better to not use abbreviations or false acronyms. so, "environment variable" |
| 00:54.48 | wpwrak | (variables) aah, now i get it (after reading the last line). they're your environment variables. okay, so you want to explain them in the usage. how about ... 1) putting them at the end of the description of the corresponding option, 2) making an extra column for variables, or 3) explaining the mapping at the end, where you introduce the environment variables? |
| 00:55.11 | DocScrutinizer05 | (2nd) it's more to it than just number of runs. It also doesn't check DMM's ident response, it doesn't print timestamp, and generally it's streamlined for performance in 2nd syntax |
| 00:55.57 | DocScrutinizer05 | (("in between" is like "dazwischen")) ... which is exactly what's meant |
| 00:56.50 | DocScrutinizer05 | on between multiple results in one line, each of which is the result to one of multiple cmds run for each sample event |
| 00:56.54 | wpwrak | by the way, i'm not sure it's such a great idea to use a lot of possibly very common variable names. maybe add a prefix ? |
| 00:57.09 | DocScrutinizer05 | :nod: |
| 00:57.37 | wpwrak | (in between) "dazwischen", not "zwischen" ? |
| 00:58.08 | DocScrutinizer05 | ((and then joerg fell asleep )) no, then the line looked like EOL |
| 00:58.23 | DocScrutinizer05 | aah, ok |
| 00:59.08 | wpwrak | (difference to "u1233 cmd") okay, maybe mention the things that the 2nd form doesn't do. (or at least that it doesn't do some things. from the description it isn't clear that it's not identical to -c 1) |
| 01:00.45 | DocScrutinizer05 | ((-E seems a little odd)) see http://paste.opensuse.org/90468020, when the DMM doesn't answer, the line starts with ";" since no response. -E "NAN" would make that look "NAN;" |
| 01:00.46 | wpwrak | btw, i'd also drop the quotes around <str>. 1) because they're often not necessary (e.g., -d "/" is just -d /), 2) because you sometimes wouldn't want double quotes but single quotes |
| 01:01.26 | DocScrutinizer05 | :nod: |
| 01:01.40 | wpwrak | (-E) why not abort by default ? and only display something if the user puts -E ? |
| 01:01.57 | DocScrutinizer05 | it does abort by default, when -E not given |
| 01:02.11 | wpwrak | aah, that's not clear :) |
| 01:02.43 | wpwrak | in fact, it says "instead of <result>", so that suggests "silent failure" is the default |
| 01:03.35 | DocScrutinizer05 | tbh i'm not decided on it yet |
| 01:04.06 | DocScrutinizer05 | so you think abort should be default? |
| 01:04.47 | DocScrutinizer05 | and epty output (like seen on http://paste.opensuse.org/90468020 ) would only happen on -E "" |
| 01:04.54 | wpwrak | the description of -S is also a bit odd. first, why is the default the epoc ? (and "epoch" is a normal english word, while EPOC was an operating system) |
| 01:05.14 | wpwrak | and second, why is the start (!) time epoch + n * interval ? |
| 01:05.50 | wpwrak | (abort default) yes, if there's an error, you normally want to know about it |
| 01:06.19 | DocScrutinizer05 | saturn:~ # date; interval=5 count=10 print_n=y del0=":" dateformat="battery level at %H:%M:.%4N" del=' --- ' u1233 "SYST:BATT?" continuous |
| 01:06.21 | DocScrutinizer05 | Sat Jan 24 10:20:22 CET 2015 |
| 01:06.22 | wpwrak | i mean further processing steps may completely hide any unusual response. e.g., C's atof |
| 01:06.22 | DocScrutinizer05 | 1:95% --- battery level at 10:20:25.0352 |
| 01:06.24 | DocScrutinizer05 | 2:95% --- battery level at 10:20:30.0220 |
| 01:07.03 | DocScrutinizer05 | virtual #0 would be Sat Jan 24 10:20:20 CET 2015 |
| 01:07.29 | DocScrutinizer05 | which is epoch + (N * 5s) |
| 01:07.37 | wpwrak | that sounds like system time, no ? |
| 01:08.03 | wpwrak | the beginning of the unix epoch is january 1st 1970 |
| 01:08.14 | DocScrutinizer05 | no, I'm using seconds since epoch for all calculations |
| 01:09.27 | wpwrak | and i think epoch + n * interval is the time of the nth sample, not the start time of the series, no ? |
| 01:09.46 | DocScrutinizer05 | for an interval of 5s you want a start time (and subsequent time pace) of 10:20:20 10:20:25 10:20:30 ... -- NOT 10:20:22 10:20:27 10:20:32 |
| 01:11.18 | DocScrutinizer05 | this when starting command at Sat Jan 24 10:20:22 CET 2015 the starttime is calculated as Sat Jan 24 10:20:20 CET 2015 for the virtual (non-existent) 0th sample |
| 01:11.46 | DocScrutinizer05 | and sample #1 is 5s later than that: 1:95% --- battery level at 10:20:25.0352 |
| 01:12.33 | DocScrutinizer05 | you however can override that calculation by manually giving starttime |
| 01:13.25 | DocScrutinizer05 | e.g when you want a sample every 10 minutes, but don't want to wait for first sample 8 minutes at Sat Jan 24 10:20:22 CET 2015 |
| 01:14.11 | wpwrak | hmm. the description is confusing then |
| 01:14.24 | DocScrutinizer05 | the whole concept is pretty complex |
| 01:14.35 | wpwrak | first, the concept of index0 is confusing since you never see the time you specify |
| 01:15.12 | wpwrak | second, you could just say that the first sample starts at a virtual time that's the next multiple of the interval |
| 01:15.28 | DocScrutinizer05 | :nod: |
| 01:15.43 | wpwrak | but i wouldn't make this the default. rather just use whatever the current time is as default |
| 01:16.04 | DocScrutinizer05 | that would result in 0:20:22 10:20:27 10:20:32 |
| 01:16.17 | wpwrak | yes. which is what one would normally expect |
| 01:16.36 | wpwrak | you could use -S "" for the rounding you prefer |
| 01:16.55 | DocScrutinizer05 | I'll ponder it |
| 01:17.00 | wpwrak | ah, and do you adjust for drift ? |
| 01:17.09 | DocScrutinizer05 | hmm? |
| 01:17.20 | wpwrak | how do you implement the interval ? sleep ? |
| 01:17.30 | DocScrutinizer05 | complex ;-) |
| 01:18.02 | DocScrutinizer05 | yes, sleep, calculated down to the nanosecond from now to next scheduled rasterpoint |
| 01:18.14 | wpwrak | so you compensate for execution time. good. |
| 01:19.01 | wpwrak | hmm. batman just tried a home invasion. |
| 01:19.15 | DocScrutinizer05 | yes, I accept systemic offset but compensate for all drift |
| 01:19.17 | wpwrak | changed his mind at the last minute |
| 01:19.45 | DocScrutinizer05 | the offset is ~ 20ms |
| 01:20.12 | DocScrutinizer05 | though I can tell so only for the time of timestamp date(1) invocation |
| 01:20.26 | DocScrutinizer05 | ;-) |
| 01:20.27 | wpwrak | guess batman didn't want to wrestle with a member the global apex predator species today ;) |
| 01:21.07 | wpwrak | yeah, in a shell script you can't expect to always get very precise timing |
| 01:22.03 | DocScrutinizer05 | in the end of "the day" I have no clue at all when DMM did last sample/conversion |
| 01:23.05 | DocScrutinizer05 | 20ms seems way beyond all discussion though |
| 01:23.16 | DocScrutinizer05 | particularly at 9600 baud |
| 01:24.10 | DocScrutinizer05 | and usual jitter is <100ms as well |
| 01:24.40 | DocScrutinizer05 | drift is zilch, versus system time |
| 01:26.57 | DocScrutinizer05 | in http://paste.opensuse.org/90468020 see the timestamps, and also see the "*0" result which is actually what the DMM tells when switching it from "off" to first position to the left (V_Z-low) |
| 01:28.36 | DocScrutinizer05 | usual skew/offset is around .0205 |
| 01:28.52 | DocScrutinizer05 | aka 20.5ms |
| 01:29.30 | DocScrutinizer05 | well, on *this* PC at least |
| 02:09.03 | *** join/#qi-hardware arossdotme1 (~butler@79-69-192-57.dynamic.dsl.as9105.com) |
| 02:09.39 | *** join/#qi-hardware qi-bot7 (~qi-bot@turandot.qi-hardware.com) |
| 02:10.00 | *** join/#qi-hardware kyak_ (~kyak@unaffiliated/kyak) |
| 02:16.26 | *** mode/#qi-hardware [+o qi-bot] by ChanServ |
| 02:18.55 | *** join/#qi-hardware freespace (~steve@stark.pictorii.com) |
| 02:21.25 | wpwrak | if you want to do it with proper german precision, then you'll show the time when the command was sent and the time when the (last part of) the result was received ;-) |
| 02:26.19 | DocScrutinizer05 | I don't know when the first bit of cmd gets sent, I have no control of the lower layers of that stack ;-) all I know is the time the subsequently called (shell internal?) date(1) command got the time() from system. I can do similar botch before I start sending the command |
| 02:27.41 | wpwrak | yes, but you know when you ask the thing to be sent. so this would be your interval. of course, if things happen completely asynchronously, e.g., if you have multiple commands or responses in flight, then that wouldn't work |
| 02:29.11 | DocScrutinizer05 | 03:28:31.001768737 --- +5.48000000E-02;03:28:31.031068996 |
| 02:30.42 | *** join/#qi-hardware sulky_ (~sulky@192.71.247.71) |
| 02:31.10 | DocScrutinizer05 | I neither do know when "ask the thing to be sent", I only know when the date command called *before* I invoke the send command gets the time from systime() |
| 02:31.57 | DocScrutinizer05 | which seems to be 1ms after the ssheduled time |
| 02:33.12 | DocScrutinizer05 | then I call the subroutine which sends, receives the response and prints it to stdout, then I call date again and when that agan calls sysdate() it's 30ms later than first sysdate() |
| 02:33.54 | DocScrutinizer05 | well 29.3 |
| 02:34.39 | DocScrutinizer05 | <PROTECTED> |
| 02:36.34 | *** join/#qi-hardware arossdotme (~butler@79-69-192-57.dynamic.dsl.as9105.com) |
| 02:40.39 | *** join/#qi-hardware dandon_ (~dandon@88.151.74.148) |
| 02:41.06 | *** join/#qi-hardware nicksydney (~quassel@43.230.dsl.syd.iprimus.net.au) |
| 02:43.11 | *** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 02:43.23 | DocScrutinizer05 | ~botsnack |
| 02:43.23 | infobot | DocScrutinizer05: aw, gee |
| 02:43.27 | *** join/#qi-hardware luke-jr_ (~luke-jr@unaffiliated/luke-jr) |
| 02:43.33 | DocScrutinizer05 | rajaniemi.freenode.net down, eh? |
| 02:44.03 | DocScrutinizer05 | yup |
| 02:44.38 | *** join/#qi-hardware kyak (~kyak@128-72-104-157.broadband.corbina.ru) |
| 02:44.38 | *** join/#qi-hardware kyak (~kyak@unaffiliated/kyak) |
| 02:44.45 | DocScrutinizer05 | of course multiple concurrent commands would make stuff messy, as would do unsolicited responses that need to get handled async. However I don't see how that would work at all with such simple protocol. It usually fails even for AT interface of modem |
| 02:46.33 | DocScrutinizer05 | well, I guess I could use read instead of sleep for the timing, this would allow to wait for sigalarm _and_ for inbound data concurrently |
| 02:49.54 | DocScrutinizer05 | however a "collision" where DMM sends some unsolicited response while the program just sends a command and thus expects a valid response to such command, will not be resolvable |
| 02:49.54 | *** join/#qi-hardware viric (~viric@unaffiliated/viric) |
| 02:49.54 | DocScrutinizer05 | o.O |
| 02:55.51 | *** join/#qi-hardware wpwrak (~werner@154-164-231-201.fibertel.com.ar) |
| 02:56.02 | *** join/#qi-hardware dandon (~dandon@88.151.74.148) |
| 03:11.36 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a027:21::4e) |
| 03:24.30 | DocScrutinizer05 | wpwrak: wb! |
| 03:24.56 | DocScrutinizer05 | HMMMPHH http://paste.opensuse.org/22496515 |
| 03:25.08 | wpwrak | did you get the last part about intervals ? "[...] then so be it. the interval is still accurate." |
| 03:26.00 | DocScrutinizer05 | nope |
| 03:27.30 | wpwrak | yes, that's how you do such intervals. take the latest possible point where you can be sure that it's before the moment (or interval) X when the sample is taken, and the first possible point where you can be sure that it's after the taking of the sample |
| 03:27.34 | wpwrak | if your implementation / infrastructure spends a lot of time between these two points, then so be it. the interval is still accurate. |
| 03:27.41 | wpwrak | (just these two) |
| 09:57.18 | *** join/#qi-hardware infobot (ibot@rikers.org) |
| 09:57.18 | *** topic/#qi-hardware is Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware |
| 09:57.18 | *** mode/#qi-hardware [+v infobot] by ChanServ |
| 10:47.01 | *** join/#qi-hardware xiangfu (~xiangfu@123.125.212.79) |
| 11:40.45 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a027:21::4e) |
| 11:54.16 | *** join/#qi-hardware xiangfu (~xiangfu@123.125.212.79) |
| 11:57.46 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a027:21::4e) |
| 12:34.52 | *** join/#qi-hardware xiangfu (~xiangfu@123.125.212.79) |
| 13:19.46 | *** join/#qi-hardware valhalla (~valhalla@88-149-237-168.v4.ngi.it) |
| 13:47.58 | *** join/#qi-hardware xiangfu (~xiangfu@123.125.212.79) |
| 14:04.58 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a027:21::4e) |
| 14:33.33 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a027:21::4e) |
| 15:29.31 | *** join/#qi-hardware jekhor (~jek@port-160-adslby-pool43.infonet.by) |
| 15:37.16 | *** join/#qi-hardware jekhor_ (~jek@port-160-adslby-pool43.infonet.by) |
| 15:39.49 | *** join/#qi-hardware wpwrak (~werner@154-164-231-201.fibertel.com.ar) |
| 15:51.05 | sb0 | http://nist.gov/pml/div688/grp10/open-source-software-for-quantum-information.cfm |
| 16:51.19 | *** join/#qi-hardware jekhor__ (~jek@port-160-adslby-pool43.infonet.by) |
| 19:12.50 | *** join/#qi-hardware jekhor__ (~jek@nat-minsk-pool-46-53-200-14.telecom.by) |
| 20:54.52 | *** join/#qi-hardware jekhor__ (~jek@nat-minsk-pool-46-53-200-14.telecom.by) |
| 21:10.00 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a027:21::4e) |
| 21:32.22 | *** join/#qi-hardware rejon (~rejon@2600:100a:b11b:a266:223:15ff:fe2a:9c6c) |
| 22:06.02 | *** join/#qi-hardware lrockhq (~AOv2@unaffiliated/sirlongrock) |
| 22:36.59 | *** join/#qi-hardware idundidit (~idundidit@66-215-119-163.dhcp.atsc.ca.charter.com) |
| 23:36.42 | *** join/#qi-hardware Haswell (~Haswell@unaffiliated/haswell) |