<wpwrak>
2nd invocation variant seems to be redundant. you could just say that "-c <int>" defaults to 1.
<wpwrak>
"dateformat of timestamp right to result" doesn't parse. did you mean "right next" ?
<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 ?
<wpwrak>
"(1)date +format" looks confusing. better to just omit the "(1)"
<wpwrak>
"separator/delimiter in between" no "in". "in between" is like "dazwischen"
<wpwrak>
"May occcur multi" ... and then joerg fell asleep ;-)
<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
<wpwrak>
"index0" space missing ?
<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"
<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?
<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
<DocScrutinizer05>
(("in between" is like "dazwischen")) ... which is exactly what's meant
<DocScrutinizer05>
on between multiple results in one line, each of which is the result to one of multiple cmds run for each sample event
<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 ?
<DocScrutinizer05>
:nod:
<wpwrak>
(in between) "dazwischen", not "zwischen" ?
<DocScrutinizer05>
((and then joerg fell asleep )) no, then the line looked like EOL
<DocScrutinizer05>
aah, ok
<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)
<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;"
<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
<DocScrutinizer05>
:nod:
<wpwrak>
(-E) why not abort by default ? and only display something if the user puts -E ?
<DocScrutinizer05>
it does abort by default, when -E not given
<wpwrak>
aah, that's not clear :)
<wpwrak>
in fact, it says "instead of <result>", so that suggests "silent failure" is the default
<DocScrutinizer05>
tbh i'm not decided on it yet
<DocScrutinizer05>
so you think abort should be default?
<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)
<wpwrak>
and second, why is the start (!) time epoch + n * interval ?
<wpwrak>
(abort default) yes, if there's an error, you normally want to know about it
<wpwrak>
i mean further processing steps may completely hide any unusual response. e.g., C's atof
<DocScrutinizer05>
1:95% --- battery level at 10:20:25.0352
<DocScrutinizer05>
2:95% --- battery level at 10:20:30.0220
<DocScrutinizer05>
virtual #0 would be Sat Jan 24 10:20:20 CET 2015
<DocScrutinizer05>
which is epoch + (N * 5s)
<wpwrak>
that sounds like system time, no ?
<wpwrak>
the beginning of the unix epoch is january 1st 1970
<DocScrutinizer05>
no, I'm using seconds since epoch for all calculations
<wpwrak>
and i think epoch + n * interval is the time of the nth sample, not the start time of the series, no ?
<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
<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
<DocScrutinizer05>
and sample #1 is 5s later than that: 1:95% --- battery level at 10:20:25.0352
<DocScrutinizer05>
you however can override that calculation by manually giving starttime
<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
<wpwrak>
hmm. the description is confusing then
<DocScrutinizer05>
the whole concept is pretty complex
<wpwrak>
first, the concept of index0 is confusing since you never see the time you specify
<wpwrak>
second, you could just say that the first sample starts at a virtual time that's the next multiple of the interval
<DocScrutinizer05>
:nod:
<wpwrak>
but i wouldn't make this the default. rather just use whatever the current time is as default
<DocScrutinizer05>
that would result in 0:20:22 10:20:27 10:20:32
<wpwrak>
yes. which is what one would normally expect
<wpwrak>
you could use -S "" for the rounding you prefer
xiangfu has quit [Remote host closed the connection]
<DocScrutinizer05>
I'll ponder it
<wpwrak>
ah, and do you adjust for drift ?
<DocScrutinizer05>
hmm?
<wpwrak>
how do you implement the interval ? sleep ?
<DocScrutinizer05>
complex ;-)
<DocScrutinizer05>
yes, sleep, calculated down to the nanosecond from now to next scheduled rasterpoint
<wpwrak>
so you compensate for execution time. good.
<wpwrak>
hmm. batman just tried a home invasion.
<DocScrutinizer05>
yes, I accept systemic offset but compensate for all drift
<wpwrak>
changed his mind at the last minute
<DocScrutinizer05>
the offset is ~ 20ms
<DocScrutinizer05>
though I can tell so only for the time of timestamp date(1) invocation
<DocScrutinizer05>
;-)
<wpwrak>
guess batman didn't want to wrestle with a member the global apex predator species today ;)
<wpwrak>
yeah, in a shell script you can't expect to always get very precise timing
<DocScrutinizer05>
in the end of "the day" I have no clue at all when DMM did last sample/conversion
<DocScrutinizer05>
20ms seems way beyond all discussion though
<DocScrutinizer05>
particularly at 9600 baud
<DocScrutinizer05>
and usual jitter is <100ms as well
<DocScrutinizer05>
drift is zilch, versus system time
<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)
<DocScrutinizer05>
usual skew/offset is around .0205
<DocScrutinizer05>
aka 20.5ms
<DocScrutinizer05>
well, on *this* PC at least
arossdotme1 has joined #qi-hardware
qi-bot7 has joined #qi-hardware
kyak_ has joined #qi-hardware
kyak has quit [*.net *.split]
qi-bot has quit [*.net *.split]
arossdotme has quit [*.net *.split]
freespac1 has quit [*.net *.split]
qi-bot7 is now known as qi-bot
freespace has joined #qi-hardware
<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 ;-)
<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
<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
<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()
<DocScrutinizer05>
which seems to be 1ms after the ssheduled time
<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()
<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
<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
kyak_ has quit [*.net *.split]
Luke-Jr has quit [*.net *.split]
viric has quit [*.net *.split]
wpwrak has quit [*.net *.split]
<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
<wpwrak>
did you get the last part about intervals ? "[...] then so be it. the interval is still accurate."
<DocScrutinizer05>
nope
<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
<wpwrak>
if your implementation / infrastructure spends a lot of time between these two points, then so be it. the interval is still accurate.
<wpwrak>
(just these two)
luke-jr_ is now known as Luke-Jr
<DocScrutinizer05>
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´
<DocScrutinizer05>
ok, sorry, this thing will not handle interval periods >= 10000000 seconds
lrockhq has joined #qi-hardware
<DocScrutinizer05>
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<<
<DocScrutinizer05>
I stretched the period a bit, too. now 100000000 seconds max
<DocScrutinizer05>
the interval actually, aka sampling rate
lrockhq has quit [Read error: Connection reset by peer]
lrockhq has joined #qi-hardware
<DocScrutinizer05>
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
lrockhq has quit [Quit: Leaving]
<wpwrak>
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 ;)
<wpwrak>
besides, if i have the whole series, i can trivially subtract the start time
rejon has quit [Ping timeout: 245 seconds]
<DocScrutinizer05>
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
<wpwrak>
so now we'll have to scan your screenshots for terrorist messages, too :)
<DocScrutinizer05>
hehe
Haswell has quit [Quit: Saliendo]
<DocScrutinizer05>
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