#qi-hardware IRC log for Sunday, 2015-01-25

wpwraknicksydney: their marketing is good :)00:00
DocScrutinizer05wpwrak: please check helptext and the interface semantics00:23
DocScrutinizer05actually http://paste.opensuse.org/6255974300:37
wpwrak2nd invocation variant seems to be redundant. you could just say that "-c <int>" defaults to 1.00:44
wpwrak"dateformat of timestamp right to result" doesn't parse. did you mean "right next" ?00:45
wpwrakalso, 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:46
wpwrak"(1)date +format" looks confusing. better to just omit the "(1)"00:47
wpwrak"separator/delimiter in between" no "in". "in between" is like "dazwischen"00:48
wpwrak"May occcur multi" ... and then joerg fell asleep ;-)00:49
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 there00:50
wpwrak"index0" space missing ?00:50
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:52
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:54
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 syntax00:55
DocScrutinizer05(("in between" is like "dazwischen")) ... which is exactly what's meant00:55
DocScrutinizer05on between multiple results in one line, each of which is the result to one of multiple cmds run for each sample event00:56
wpwrakby 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:56
wpwrak(in between) "dazwischen", not "zwischen" ?00:57
DocScrutinizer05((and then joerg fell asleep )) no, then the line looked like EOL00:58
DocScrutinizer05aah, ok00:58
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)00:59
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
wpwrakbtw, 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 quotes01:00
wpwrak(-E) why not abort by default ? and only display something if the user puts -E ?01:01
DocScrutinizer05it does abort by default, when -E not given01:01
wpwrakaah, that's not clear :)01:02
wpwrakin fact, it says "instead of <result>", so that suggests "silent failure" is the default01:02
DocScrutinizer05tbh i'm not decided on it yet01:03
DocScrutinizer05so you think abort should be default? 01:04
DocScrutinizer05and epty output (like seen on http://paste.opensuse.org/90468020 ) would only happen on -E ""01:04
wpwrakthe 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:04
wpwrakand second, why is the start (!) time epoch + n * interval ?01:05
wpwrak(abort default) yes, if there's an error, you normally want to know about it01:05
DocScrutinizer05saturn:~ # date; interval=5 count=10 print_n=y del0=":" dateformat="battery level at %H:%M:.%4N" del=' --- '  u1233 "SYST:BATT?" continuous01:06
DocScrutinizer05Sat Jan 24 10:20:22 CET 201501:06
wpwraki mean further processing steps may completely hide any unusual response. e.g., C's atof01:06
DocScrutinizer051:95% --- battery level at 10:20:25.035201:06
DocScrutinizer052:95% --- battery level at 10:20:30.022001:06
DocScrutinizer05virtual #0 would be Sat Jan 24 10:20:20 CET 201501:07
DocScrutinizer05which is epoch + (N * 5s)01:07
wpwrakthat sounds like system time, no ?01:07
wpwrakthe beginning of the unix epoch is january 1st 197001:08
DocScrutinizer05no, I'm using seconds since epoch for all calculations01:08
wpwrakand i think epoch + n * interval is the time of the nth sample, not the start time of the series, no ?01:09
DocScrutinizer05for 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:3201:09
DocScrutinizer05this 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 sample01:11
DocScrutinizer05and sample #1 is 5s later than that: 1:95% --- battery level at 10:20:25.035201:11
DocScrutinizer05you however can override that calculation by manually giving starttime01:12
DocScrutinizer05e.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 201501:13
wpwrakhmm. the description is confusing then01:14
DocScrutinizer05the whole concept is pretty complex01:14
wpwrakfirst, the concept of index0 is confusing since you never see the time you specify01:14
wpwraksecond, you could just say that the first sample starts at a virtual time that's the next multiple of the interval01:15
wpwrakbut i wouldn't make this the default. rather just use whatever the current time is as default01:15
DocScrutinizer05that would result in 0:20:22 10:20:27 10:20:3201:16
wpwrakyes. which is what one would normally expect01:16
wpwrakyou could use  -S ""  for the rounding you prefer01:16
DocScrutinizer05I'll ponder it01:16
wpwrakah, and do you adjust for drift ?01:17
wpwrakhow do you implement the interval ? sleep ?01:17
DocScrutinizer05complex ;-)01:17
DocScrutinizer05yes, sleep, calculated down to the nanosecond from now to next scheduled rasterpoint01:18
wpwrakso you compensate for execution time. good.01:18
wpwrakhmm. batman just tried a home invasion.01:19
DocScrutinizer05yes, I accept systemic offset but compensate for all drift01:19
wpwrakchanged his mind at the last minute01:19
DocScrutinizer05the offset is ~ 20ms01:19
DocScrutinizer05though I can tell so only for the time of timestamp date(1) invocation01:20
wpwrakguess batman didn't want to wrestle with a member the global apex predator species today ;)01:20
wpwrakyeah, in a shell script you can't expect to always get very precise timing01:21
DocScrutinizer05in the end of "the day" I have no clue at all when DMM did last sample/conversion01:22
DocScrutinizer0520ms seems way beyond all discussion though01:23
DocScrutinizer05particularly at 9600 baud01:23
DocScrutinizer05and usual jitter is <100ms as well01:24
DocScrutinizer05drift is zilch, versus system time01:24
DocScrutinizer05in 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:26
DocScrutinizer05usual skew/offset is around .020501:28
DocScrutinizer05aka 20.5ms01:28
DocScrutinizer05well, on *this* PC at least01:29
wpwrakif 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:21
DocScrutinizer05I 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 command02:26
wpwrakyes, 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 work02:27
DocScrutinizer0503:28:31.001768737 --- +5.48000000E-02;03:28:31.03106899602:29
DocScrutinizer05I 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
DocScrutinizer05which seems to be 1ms after the ssheduled time02:31
DocScrutinizer05then 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
DocScrutinizer05well 29.302:33
DocScrutinizer05      echo "`date "+${dateformat}"` --- `docmd "$1"`${del}`date "+${dateformat}"`";02:34
infobotDocScrutinizer05: aw, gee02:43
DocScrutinizer05rajaniemi.freenode.net down, eh?02:43
DocScrutinizer05of 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 modem02:44
DocScrutinizer05well, I guess I could use read instead of sleep for the timing, this would allow to wait for sigalarm _and_ for inbound data concurrently02:46
DocScrutinizer05however 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 resolvable02:49
DocScrutinizer05wpwrak: wb!03:24
DocScrutinizer05HMMMPHH  http://paste.opensuse.org/2249651503:24
wpwrakdid you get the last part about intervals ? "[...] then so be it. the interval is still accurate."03:25
wpwrakyes, 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 sample03:27
wpwrakif your implementation / infrastructure spends a lot of time between these two points, then so be it. the interval is still accurate.03:27
wpwrak(just these two)03:27
DocScrutinizer05would you be willing to have a look at my code and see if you can spot why "/usr/local/bin/u1233: Zeile 153: -9: Teilstring-Ausdruck < 0."   aka  `dang "${nsdelta: +0:-9}.${nsdelta: -9}" blows chunks. Prolly because it's too short´03:37
DocScrutinizer05wpwrak: http://paste.opensuse.org/9930607603:39
wpwrakyes, that sounds like a plausible explanation. if |length| > len(string), then bash complains03:44
DocScrutinizer05yes, but how can nsdelta ever be too short?03:48
DocScrutinizer05trailing zeroes?03:48
DocScrutinizer05date +%s%N  ?03:49
DocScrutinizer05--> date +%s%9N  ?03:50
DocScrutinizer05jr@saturn:~> date +%s%N03:51
DocScrutinizer05jr@saturn:~> date +%s%N03:51
DocScrutinizer05sth in the line "nsdelta=$(( ((starttime + n * interval) * 1000000000) - `date +%s%N` ));" goes haywire03:55
DocScrutinizer05ohshit, leading zeroes03:56
DocScrutinizer05I hate that stuff03:57
DocScrutinizer05oooooo...  kay:  ... + 10000000000000000000;  ${nsdelta: +0:-9} --> ${nsdelta: +1:-9}04:00
DocScrutinizer05just lucky that read -t 00000000000000000000.5 succeeds04:04
DocScrutinizer05F!! U!! Bash!!04:25
DocScrutinizer05jr@saturn:~> echo $nsd; nsd=$(( nsd + 10000000000000000000 )); echo $nsd;04:25
DocScrutinizer05ok, sorry, this thing will not handle interval periods >= 10000000 seconds04:42
DocScrutinizer05ok, http://paste.opensuse.org/62014122 -- collisions in e.g. >>"RES,5"; *2; 05:47:30.031451037 \n unsolicited: +1.91111000E+00<<  and  >>*3; "RES,0"; 05:48:22.019086294  \n  unsolicited: +3.15000000E+00<<04:53
DocScrutinizer05I stretched the period a bit, too. now 100000000 seconds max04:55
DocScrutinizer05the interval actually, aka sampling rate04:55
DocScrutinizer05wpwrak: I see. My approach was from doing days of recording, of stuff like weather etc. Thus I thought of time scale as absolute datetime. Usually in a lab however you do tests on setups and there you're not interested in absolute but in relative timescale, iow starting at 00:00 with start of recording05:07
wpwrakoh, i'm very interested in absolute (local) time ;) because, for example, temperature changes with time. and pretty much everything you can measure in a lab changes with temperature ;)05:21
wpwrakbesides, if i have the whole series, i can trivially subtract the start time05:22
DocScrutinizer05ooh, Rigol .bmp and ELEMENTARY quote about stegano gave me some ideas of simply appending files of arbitrary data to .bmp. Not exactly good stegano, but hidden enough for 99.9% of casual lurkers and feasible with pretty dead-simple standard linux tools too05:47
wpwrakso now we'll have to scan your screenshots for terrorist messages, too :)05:57
DocScrutinizer05I start to dislike the syntax/semantics of the u1233 tool UI. Will prolly change it towards interpreter, with virtually every option becoming a command like the SCPI commands. So everything starting from commands to delimiters to timestamp is just a command and the whole sequence of commands forms the "format string" for the output06:34
DocScrutinizer05txt=sample-nr: var=n "txt=; " cmd=FETC?!num-of-results=1 "txt: --- timestamp:" "var=timestamp-abs!%H%M \n" 06:41
wpwrakbrilliant conversation: bruce schneier and ed snowden: https://www.youtube.com/watch?v=7Ui3tLbzIgQ06:43
DocScrutinizer05txt=sample-nr: var=n "txt=; " cmd=FETC?!num-of-results=1 "txt= --- timestamp:" "var=timestamp-abs!%H%M%S \n" 06:43

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