2015-01-25 00:00 nicksydney: their marketing is good :) 2015-01-25 00:23 wpwrak: please check helptext and the interface semantics 2015-01-25 00:23 http://paste.opensuse.org/34737169 2015-01-25 00:31 xiangfu has joined #qi-hardware 2015-01-25 00:37 actually http://paste.opensuse.org/62559743 2015-01-25 00:44 2nd invocation variant seems to be redundant. you could just say that "-c " defaults to 1. 2015-01-25 00:45 "dateformat of timestamp right to result" doesn't parse. did you mean "right next" ? 2015-01-25 00:46 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 ? 2015-01-25 00:47 "(1)date +format" looks confusing. better to just omit the "(1)" 2015-01-25 00:48 "separator/delimiter in between" no "in". "in between" is like "dazwischen" 2015-01-25 00:49 "May occcur multi" ... and then joerg fell asleep ;-) 2015-01-25 00:50 -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 2015-01-25 00:50 "index0" space missing ? 2015-01-25 00:52 "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" 2015-01-25 00:54 (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? 2015-01-25 00:55 (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 2015-01-25 00:55 (("in between" is like "dazwischen")) ... which is exactly what's meant 2015-01-25 00:56 on between multiple results in one line, each of which is the result to one of multiple cmds run for each sample event 2015-01-25 00:56 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 ? 2015-01-25 00:57 :nod: 2015-01-25 00:57 (in between) "dazwischen", not "zwischen" ? 2015-01-25 00:58 ((and then joerg fell asleep )) no, then the line looked like EOL 2015-01-25 00:58 aah, ok 2015-01-25 00:59 (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) 2015-01-25 01:00 ((-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;" 2015-01-25 01:00 btw, i'd also drop the quotes around . 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 2015-01-25 01:01 :nod: 2015-01-25 01:01 (-E) why not abort by default ? and only display something if the user puts -E ? 2015-01-25 01:01 it does abort by default, when -E not given 2015-01-25 01:02 aah, that's not clear :) 2015-01-25 01:02 in fact, it says "instead of ", so that suggests "silent failure" is the default 2015-01-25 01:03 tbh i'm not decided on it yet 2015-01-25 01:04 so you think abort should be default? 2015-01-25 01:04 and epty output (like seen on http://paste.opensuse.org/90468020 ) would only happen on -E "" 2015-01-25 01:04 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) 2015-01-25 01:05 and second, why is the start (!) time epoch + n * interval ? 2015-01-25 01:05 (abort default) yes, if there's an error, you normally want to know about it 2015-01-25 01:06 saturn:~ # date; interval=5 count=10 print_n=y del0=":" dateformat="battery level at %H:%M:.%4N" del=' --- ' u1233 "SYST:BATT?" continuous 2015-01-25 01:06 Sat Jan 24 10:20:22 CET 2015 2015-01-25 01:06 i mean further processing steps may completely hide any unusual response. e.g., C's atof 2015-01-25 01:06 1:95% --- battery level at 10:20:25.0352 2015-01-25 01:06 2:95% --- battery level at 10:20:30.0220 2015-01-25 01:07 virtual #0 would be Sat Jan 24 10:20:20 CET 2015 2015-01-25 01:07 which is epoch + (N * 5s) 2015-01-25 01:07 that sounds like system time, no ? 2015-01-25 01:08 the beginning of the unix epoch is january 1st 1970 2015-01-25 01:08 no, I'm using seconds since epoch for all calculations 2015-01-25 01:09 and i think epoch + n * interval is the time of the nth sample, not the start time of the series, no ? 2015-01-25 01:09 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 2015-01-25 01:11 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 2015-01-25 01:11 and sample #1 is 5s later than that: 1:95% --- battery level at 10:20:25.0352 2015-01-25 01:12 you however can override that calculation by manually giving starttime 2015-01-25 01:13 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 2015-01-25 01:14 hmm. the description is confusing then 2015-01-25 01:14 the whole concept is pretty complex 2015-01-25 01:14 first, the concept of index0 is confusing since you never see the time you specify 2015-01-25 01:15 second, you could just say that the first sample starts at a virtual time that's the next multiple of the interval 2015-01-25 01:15 :nod: 2015-01-25 01:15 but i wouldn't make this the default. rather just use whatever the current time is as default 2015-01-25 01:16 that would result in 0:20:22 10:20:27 10:20:32 2015-01-25 01:16 yes. which is what one would normally expect 2015-01-25 01:16 you could use -S "" for the rounding you prefer 2015-01-25 01:16 xiangfu has quit [Remote host closed the connection] 2015-01-25 01:16 I'll ponder it 2015-01-25 01:17 ah, and do you adjust for drift ? 2015-01-25 01:17 hmm? 2015-01-25 01:17 how do you implement the interval ? sleep ? 2015-01-25 01:17 complex ;-) 2015-01-25 01:18 yes, sleep, calculated down to the nanosecond from now to next scheduled rasterpoint 2015-01-25 01:18 so you compensate for execution time. good. 2015-01-25 01:19 hmm. batman just tried a home invasion. 2015-01-25 01:19 yes, I accept systemic offset but compensate for all drift 2015-01-25 01:19 changed his mind at the last minute 2015-01-25 01:19 the offset is ~ 20ms 2015-01-25 01:20 though I can tell so only for the time of timestamp date(1) invocation 2015-01-25 01:20 ;-) 2015-01-25 01:20 guess batman didn't want to wrestle with a member the global apex predator species today ;) 2015-01-25 01:21 yeah, in a shell script you can't expect to always get very precise timing 2015-01-25 01:22 in the end of "the day" I have no clue at all when DMM did last sample/conversion 2015-01-25 01:23 20ms seems way beyond all discussion though 2015-01-25 01:23 particularly at 9600 baud 2015-01-25 01:24 and usual jitter is <100ms as well 2015-01-25 01:24 drift is zilch, versus system time 2015-01-25 01:26 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) 2015-01-25 01:28 usual skew/offset is around .0205 2015-01-25 01:28 aka 20.5ms 2015-01-25 01:29 well, on *this* PC at least 2015-01-25 02:09 arossdotme1 has joined #qi-hardware 2015-01-25 02:09 qi-bot7 has joined #qi-hardware 2015-01-25 02:10 kyak_ has joined #qi-hardware 2015-01-25 02:16 kyak has quit [*.net *.split] 2015-01-25 02:16 qi-bot has quit [*.net *.split] 2015-01-25 02:16 arossdotme has quit [*.net *.split] 2015-01-25 02:16 freespac1 has quit [*.net *.split] 2015-01-25 02:16 qi-bot7 is now known as qi-bot 2015-01-25 02:18 freespace has joined #qi-hardware 2015-01-25 02:21 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 ;-) 2015-01-25 02:26 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 2015-01-25 02:27 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 2015-01-25 02:29 03:28:31.001768737 --- +5.48000000E-02;03:28:31.031068996 2015-01-25 02:30 sulky_ has joined #qi-hardware 2015-01-25 02:31 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() 2015-01-25 02:31 which seems to be 1ms after the ssheduled time 2015-01-25 02:33 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() 2015-01-25 02:33 well 29.3 2015-01-25 02:34 echo "`date "+${dateformat}"` --- `docmd "$1"`${del}`date "+${dateformat}"`"; 2015-01-25 02:35 sulky has quit [Ping timeout: 244 seconds] 2015-01-25 02:35 arossdotme1 has quit [*.net *.split] 2015-01-25 02:35 nicksydney has quit [*.net *.split] 2015-01-25 02:36 arossdotme has joined #qi-hardware 2015-01-25 02:40 dandon_ has joined #qi-hardware 2015-01-25 02:41 nicksydney has joined #qi-hardware 2015-01-25 02:43 DocScrutinizer05 has joined #qi-hardware 2015-01-25 02:43 ~botsnack 2015-01-25 02:43 DocScrutinizer05: aw, gee 2015-01-25 02:43 luke-jr_ has joined #qi-hardware 2015-01-25 02:43 rajaniemi.freenode.net down, eh? 2015-01-25 02:44 yup 2015-01-25 02:44 kyak has joined #qi-hardware 2015-01-25 02:44 kyak has joined #qi-hardware 2015-01-25 02:44 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 2015-01-25 02:46 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 2015-01-25 02:49 kyak_ has quit [*.net *.split] 2015-01-25 02:49 Luke-Jr has quit [*.net *.split] 2015-01-25 02:49 viric has quit [*.net *.split] 2015-01-25 02:49 wpwrak has quit [*.net *.split] 2015-01-25 02:49 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 2015-01-25 02:49 viric has joined #qi-hardware 2015-01-25 02:49 o.O 2015-01-25 02:55 wpwrak has joined #qi-hardware 2015-01-25 02:56 dandon has joined #qi-hardware 2015-01-25 02:58 dandon_ has quit [Ping timeout: 264 seconds] 2015-01-25 03:05 wej has quit [Ping timeout: 250 seconds] 2015-01-25 03:11 wej has joined #qi-hardware 2015-01-25 03:24 wpwrak: wb! 2015-01-25 03:24 HMMMPHH http://paste.opensuse.org/22496515 2015-01-25 03:25 did you get the last part about intervals ? "[...] then so be it. the interval is still accurate." 2015-01-25 03:26 nope 2015-01-25 03:27 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 2015-01-25 03:27 if your implementation / infrastructure spends a lot of time between these two points, then so be it. the interval is still accurate. 2015-01-25 03:27 (just these two) 2015-01-25 03:31 luke-jr_ is now known as Luke-Jr 2015-01-25 03:37 would 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´ 2015-01-25 03:39 wpwrak: http://paste.opensuse.org/99306076 2015-01-25 03:41 sulky has joined #qi-hardware 2015-01-25 03:44 yes, that sounds like a plausible explanation. if |length| > len(string), then bash complains 2015-01-25 03:45 rejon has joined #qi-hardware 2015-01-25 03:48 yes, but how can nsdelta ever be too short? 2015-01-25 03:48 trailing zeroes? 2015-01-25 03:49 date +%s%N ? 2015-01-25 03:50 --> date +%s%9N ? 2015-01-25 03:50 nah 2015-01-25 03:51 jr@saturn:~> date +%s%N 2015-01-25 03:51 1422157838165629303 2015-01-25 03:51 jr@saturn:~> date +%s%N 2015-01-25 03:51 1422157838813629270 2015-01-25 03:52 sulky_ has quit [Ping timeout: 628 seconds] 2015-01-25 03:52 infobot has quit [Ping timeout: 628 seconds] 2015-01-25 03:55 sth in the line "nsdelta=$(( ((starttime + n * interval) * 1000000000) - `date +%s%N` ));" goes haywire 2015-01-25 03:56 ohshit, leading zeroes 2015-01-25 03:57 I hate that stuff 2015-01-25 04:00 oooooo... kay: ... + 10000000000000000000; ${nsdelta: +0:-9} --> ${nsdelta: +1:-9} 2015-01-25 04:04 just lucky that read -t 00000000000000000000.5 succeeds 2015-01-25 04:25 F!! U!! Bash!! 2015-01-25 04:25 jr@saturn:~> echo $nsd; nsd=$(( nsd + 10000000000000000000 )); echo $nsd; 2015-01-25 04:25 1422159757000000000 2015-01-25 04:25 -7024584316709551616 2015-01-25 04:26 Haswell has joined #qi-hardware 2015-01-25 04:40 sb0 has joined #qi-hardware 2015-01-25 04:42 ok, sorry, this thing will not handle interval periods >= 10000000 seconds 2015-01-25 04:52 lrockhq has joined #qi-hardware 2015-01-25 04:53 ok, 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<< 2015-01-25 04:55 I stretched the period a bit, too. now 100000000 seconds max 2015-01-25 04:55 the interval actually, aka sampling rate 2015-01-25 04:55 lrockhq has quit [Read error: Connection reset by peer] 2015-01-25 04:56 lrockhq has joined #qi-hardware 2015-01-25 05:07 wpwrak: 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 recording 2015-01-25 05:10 lrockhq has quit [Quit: Leaving] 2015-01-25 05:21 oh, 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 ;) 2015-01-25 05:22 besides, if i have the whole series, i can trivially subtract the start time 2015-01-25 05:25 rejon has quit [Ping timeout: 245 seconds] 2015-01-25 05:47 ooh, 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 too 2015-01-25 05:57 so now we'll have to scan your screenshots for terrorist messages, too :) 2015-01-25 05:58 hehe 2015-01-25 06:08 Haswell has quit [Quit: Saliendo] 2015-01-25 06:34 I 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 output 2015-01-25 06:40 pcercuei has joined #qi-hardware 2015-01-25 06:41 txt=sample-nr: var=n "txt=; " cmd=FETC?!num-of-results=1 "txt: --- timestamp:" "var=timestamp-abs!%H%M \n" 2015-01-25 06:43 dang 2015-01-25 06:43 brilliant conversation: bruce schneier and ed snowden: https://www.youtube.com/watch?v=7Ui3tLbzIgQ 2015-01-25 06:43 txt=sample-nr: var=n "txt=; " cmd=FETC?!num-of-results=1 "txt= --- timestamp:" "var=timestamp-abs!%H%M%S \n" 2015-01-25 06:49 atommann has joined #qi-hardware 2015-01-25 07:05 wolfspraul has joined #qi-hardware 2015-01-25 07:31 atommann has quit [Quit: Leaving] 2015-01-25 08:11 jekhor has joined #qi-hardware 2015-01-25 09:43 jekhor has quit [Ping timeout: 276 seconds] 2015-01-25 09:57 infobot has joined #qi-hardware 2015-01-25 10:47 xiangfu has joined #qi-hardware 2015-01-25 11:30 wej has quit [Ping timeout: 245 seconds] 2015-01-25 11:40 wej has joined #qi-hardware 2015-01-25 11:53 xiangfu has quit [Ping timeout: 244 seconds] 2015-01-25 11:54 xiangfu has joined #qi-hardware 2015-01-25 11:55 wej has quit [Ping timeout: 245 seconds] 2015-01-25 11:57 wej has joined #qi-hardware 2015-01-25 12:21 xiangfu has quit [Remote host closed the connection] 2015-01-25 12:34 xiangfu has joined #qi-hardware 2015-01-25 12:38 xiangfu has quit [Remote host closed the connection] 2015-01-25 13:01 valhalla has quit [Ping timeout: 245 seconds] 2015-01-25 13:19 valhalla has joined #qi-hardware 2015-01-25 13:47 xiangfu has joined #qi-hardware 2015-01-25 14:00 wej has quit [Ping timeout: 250 seconds] 2015-01-25 14:04 wej has joined #qi-hardware 2015-01-25 14:20 wej has quit [Ping timeout: 272 seconds] 2015-01-25 14:33 wej has joined #qi-hardware 2015-01-25 15:24 xiangfu has quit [Quit: leaving] 2015-01-25 15:29 jekhor has joined #qi-hardware 2015-01-25 15:36 wpwrak has quit [Ping timeout: 245 seconds] 2015-01-25 15:37 jekhor_ has joined #qi-hardware 2015-01-25 15:39 wpwrak has joined #qi-hardware 2015-01-25 15:40 jekhor has quit [Ping timeout: 240 seconds] 2015-01-25 15:51 http://nist.gov/pml/div688/grp10/open-source-software-for-quantum-information.cfm 2015-01-25 15:52 rjeffries has quit [Ping timeout: 246 seconds] 2015-01-25 16:51 jekhor__ has joined #qi-hardware 2015-01-25 16:51 jekhor_ has quit [Read error: Connection reset by peer] 2015-01-25 17:22 jekhor__ has quit [Ping timeout: 264 seconds] 2015-01-25 19:12 jekhor__ has joined #qi-hardware 2015-01-25 19:23 wolfspraul has quit [Quit: leaving] 2015-01-25 20:54 jekhor__ has quit [Read error: Connection reset by peer] 2015-01-25 20:54 jekhor__ has joined #qi-hardware 2015-01-25 21:02 wej has quit [Ping timeout: 250 seconds] 2015-01-25 21:10 wej has joined #qi-hardware 2015-01-25 21:32 rejon has joined #qi-hardware 2015-01-25 21:43 rejon has quit [Ping timeout: 245 seconds] 2015-01-25 22:06 lrockhq has joined #qi-hardware 2015-01-25 22:36 idundidit has quit [Ping timeout: 246 seconds] 2015-01-25 22:36 idundidit has joined #qi-hardware 2015-01-25 23:00 lrockhq has quit [Quit: Leaving] 2015-01-25 23:01 pcercuei has quit [Ping timeout: 245 seconds] 2015-01-25 23:03 jekhor__ has quit [Ping timeout: 252 seconds] 2015-01-25 23:36 Haswell has joined #qi-hardware 2015-01-25 23:49 Haswell has quit [Quit: Saliendo]