• Waveform displays

    From Don Y@21:1/5 to All on Tue Jul 26 21:03:51 2022
    Any preferences/suggestions for displaying "expected waveforms" in support materials?

    I see white traces on black backgrounds, black traces on white backgrounds, graticule present, graticule absent, etc. Some of this is likely related to the nature of *paper* documents and the fact that color doesn't *tend* to
    be reproduced in copies.

    These are interactive "documents" so the user has some control over what
    is displayed; I'm debating how much control he should have over HOW it
    is displayed! (at an extreme, I can emulate a 'scope and let him dick
    with gain, timebase, position, etc. as it's a "solve once reuse often"
    sort of problem)

    Goal, however, is to make it easy for him to see what he *needs* to see
    and not distract him with the UI...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to blockedofcourse@foo.invalid on Wed Jul 27 07:03:22 2022
    On a sunny day (Tue, 26 Jul 2022 21:03:51 -0700) it happened Don Y <blockedofcourse@foo.invalid> wrote in <tbqdfg$2e90g$1@dont-email.me>:

    Any preferences/suggestions for displaying "expected waveforms" in support >materials?

    I see white traces on black backgrounds, black traces on white backgrounds, >graticule present, graticule absent, etc. Some of this is likely related to >the nature of *paper* documents and the fact that color doesn't *tend* to
    be reproduced in copies.

    These are interactive "documents" so the user has some control over what
    is displayed; I'm debating how much control he should have over HOW it
    is displayed! (at an extreme, I can emulate a 'scope and let him dick
    with gain, timebase, position, etc. as it's a "solve once reuse often"
    sort of problem)

    Goal, however, is to make it easy for him to see what he *needs* to see
    and not distract him with the UI...

    Maybe related, I always use black text on white background in my terminals.
    The reason is:
    the white background gives a better average brightness and requires less eye adaption
    when some text appears than a black background.

    Also when programming I set color off in the editor.
    Some people have every statement (say in C language) in some color
    That just makes thing harder to read,

    But then I read whole pages at the time,
    some people read one word at the time, others spell out words.
    For reading whole pages at the time you want as little colored shit as possible.

    And I do not like sigs and repeated text, for example
    sciencedaily.com annoys with repeated text.

    I added some ASCII output for Usenet for my scope_pic project long ago: http://panteltje.com/panteltje/pic/scope_pic/ http://panteltje.com/panteltje/pic/scope_pic/screen_dump2.txt http://panteltje.com/panteltje/pic/scope_pic/screen_dump.txt
    just for fun :-)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Don Y on Wed Jul 27 09:34:55 2022
    On 27/07/2022 05:03, Don Y wrote:
    Any preferences/suggestions for displaying "expected waveforms" in support materials?

    Personally I prefer black or clearly distinct coloured lines on a white background (and not too thick). Then I have normal colour vision.

    Blue/Green and Red are best not used at the same time for this reason.

    Excel default XY graphs are the opposite with a default line drawn by a
    three year old with a wax crayon in random pastel shades that quickly
    look all alike. I have some datasets which can crash it completely.

    I see white traces on black backgrounds, black traces on white backgrounds, graticule present, graticule absent, etc.  Some of this is likely
    related to
    the nature of *paper* documents and the fact that color doesn't *tend* to
    be reproduced in copies.

    Online publications increasingly encourage graphs in colour as opposed
    to lines in every more complex mono combos of ... .-.-. ._,_. etc.

    These are interactive "documents" so the user has some control over what
    is displayed; I'm debating how much control he should have over HOW it
    is displayed!  (at an extreme, I can emulate a 'scope and let him dick
    with gain, timebase, position, etc. as it's a "solve once reuse often"
    sort of problem)

    But does it help him see the detail. I can see maybe altering the
    timebase or trigger point might be useful sometimes.

    Goal, however, is to make it easy for him to see what he *needs* to see
    and not distract him with the UI...

    I favour a diagram that illustrates the point you are trying to make and optimised to show whatever the feature is.


    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Rid@21:1/5 to Don Y on Thu Jul 28 16:47:00 2022
    Don Y <blockedofcourse@foo.invalid> Wrote in message:r
    Any preferences/suggestions for displaying "expected waveforms" in supportmaterials?I see white traces on black backgrounds, black traces on white backgrounds,graticule present, graticule absent, etc. Some of this is likely related tothe nature of *
    paper* documents and the fact that color doesn't *tend* tobe reproduced in copies.These are interactive "documents" so the user has some control over whatis displayed; I'm debating how much control he should have over HOW itis displayed! (at an extreme,
    I can emulate a 'scope and let him dickwith gain, timebase, position, etc. as it's a "solve once reuse often"sort of problem)Goal, however, is to make it easy for him to see what he *needs* to seeand not distract him with the UI...

    Black on white, just like newspaper.

    Cheers
    --


    ----Android NewsGroup Reader---- https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Martin Rid on Thu Jul 28 18:12:13 2022
    Martin Rid wrote:
    Don Y <blockedofcourse@foo.invalid> Wrote in message:r
    Any preferences/suggestions for displaying "expected waveforms" in supportmaterials?I see white traces on black backgrounds, black traces on white backgrounds,graticule present, graticule absent, etc. Some of this is likely related tothe nature of *
    paper* documents and the fact that color doesn't *tend* tobe reproduced in copies.These are interactive "documents" so the user has some control over whatis displayed; I'm debating how much control he should have over HOW itis displayed! (at an extreme,
    I can emulate a 'scope and let him dickwith gain, timebase, position, etc. as it's a "solve once reuse often"sort of problem)Goal, however, is to make it easy for him to see what he *needs* to seeand not distract him with the UI...

    Black on white, just like newspaper.

    Cheers


    Newspaper is more "grey on grey".

    Cheers

    Phil Hobbs

    --
    Dr Philip C D Hobbs
    Principal Consultant
    ElectroOptical Innovations LLC / Hobbs ElectroOptics
    Optics, Electro-optics, Photonics, Analog Electronics
    Briarcliff Manor NY 10510

    http://electrooptical.net
    http://hobbs-eo.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to Don Y on Thu Jul 28 23:18:42 2022
    On Tuesday, July 26, 2022 at 9:04:07 PM UTC-7, Don Y wrote:
    Any preferences/suggestions for displaying "expected waveforms" in support materials?

    I see white traces on black backgrounds, black traces on white backgrounds, >graticule present, graticule absent, etc.

    Monochrome is good, because visual accomodation works well. There are
    some studies that say yellow-on-black has ideal contrast (blue light scatters easily; thus
    the sky is blue).

    For a CRT, focus will always be slightly off; that reduces contrast on black-line, so
    black-background is preferred. FOR LCD, it doesn't matter.

    Most display tech for color uses red-green-blue colors, so yellow (red+green) isn't
    ideal (not monochrome). Go with green-on-black, and graticule if it helps to know
    accurate voltages and timings (I can recall trying to hold a square up to a screenshot
    to pin down a value; not a fond memory).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Walliker@21:1/5 to All on Fri Jul 29 02:52:19 2022
    On Friday, 29 July 2022 at 07:18:46 UTC+1, whit3rd wrote:
    On Tuesday, July 26, 2022 at 9:04:07 PM UTC-7, Don Y wrote:
    Any preferences/suggestions for displaying "expected waveforms" in support materials?

    I see white traces on black backgrounds, black traces on white backgrounds, >graticule present, graticule absent, etc.
    Monochrome is good, because visual accomodation works well. There are
    some studies that say yellow-on-black has ideal contrast (blue light scatters easily; thus
    the sky is blue).

    For a CRT, focus will always be slightly off; that reduces contrast on black-line, so
    black-background is preferred. FOR LCD, it doesn't matter.

    Most display tech for color uses red-green-blue colors, so yellow (red+green) isn't
    ideal (not monochrome). Go with green-on-black, and graticule if it helps to know
    accurate voltages and timings (I can recall trying to hold a square up to a screenshot
    to pin down a value; not a fond memory).

    At all costs avoid yellow on a white background.

    John

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to John Walliker on Fri Jul 29 14:38:22 2022
    On Friday, July 29, 2022 at 2:52:22 AM UTC-7, John Walliker wrote:
    On Friday, 29 July 2022 at 07:18:46 UTC+1, whit3rd wrote:
    On Tuesday, July 26, 2022 at 9:04:07 PM UTC-7, Don Y wrote:
    Any preferences/suggestions for displaying "expected waveforms" in support
    materials?

    At all costs avoid yellow on a white background.

    Yeah, the anti-counterfeit constellations of "5" on USA fives, "10" on tens etc.
    has almost completely escaped public notice. Cuz, it's yellow on white...

    I'm told that lots of better-quality printers (and maybe scanners?) refuse to work with that pattern.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From amdx@21:1/5 to All on Fri Jul 29 19:05:01 2022
    On 7/29/2022 4:38 PM, whit3rd wrote:
    On Friday, July 29, 2022 at 2:52:22 AM UTC-7, John Walliker wrote:
    On Friday, 29 July 2022 at 07:18:46 UTC+1, whit3rd wrote:
    On Tuesday, July 26, 2022 at 9:04:07 PM UTC-7, Don Y wrote:
    Any preferences/suggestions for displaying "expected waveforms" in support >>>> materials?
    At all costs avoid yellow on a white background.
    Yeah, the anti-counterfeit constellations of "5" on USA fives, "10" on tens etc.
    has almost completely escaped public notice. Cuz, it's yellow on white...

    I'm told that lots of better-quality printers (and maybe scanners?) refuse to work with that pattern.
    Certainly not Grey print on a simulated aluminum diamond plate! I
    visited a website years ago with that.
    I had to copy and paste the text into Word or Notepad to read it.

    --
    This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to whit3rd@gmail.com on Sat Jul 30 03:52:38 2022
    On a sunny day (Fri, 29 Jul 2022 14:38:22 -0700 (PDT)) it happened whit3rd <whit3rd@gmail.com> wrote in <471ba0b1-73c5-4611-933d-a8b2c92275b1n@googlegroups.com>:

    On Friday, July 29, 2022 at 2:52:22 AM UTC-7, John Walliker wrote:
    On Friday, 29 July 2022 at 07:18:46 UTC+1, whit3rd wrote:
    On Tuesday, July 26, 2022 at 9:04:07 PM UTC-7, Don Y wrote:
    Any preferences/suggestions for displaying "expected waveforms" in support
    materials?

    At all costs avoid yellow on a white background.

    Yeah, the anti-counterfeit constellations of "5" on USA fives, "10" on tens etc.
    has almost completely escaped public notice. Cuz, it's yellow on white...

    I'm told that lots of better-quality printers (and maybe scanners?) refuse to work with that pattern.

    If you go by the color TV standard, then white is about:
    .3 red .59 green and .11 blue
    (eye sensitivity depending on standard, this is used here)
    For contrast using yellow (red + green) on white give 1 / .89
    or in normal speak yellow is almost as bright as white.
    The other color contrasts are easily calculated in the same way,

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Martin Brown on Sat Jul 30 17:19:10 2022
    On 7/27/2022 1:34 AM, Martin Brown wrote:
    On 27/07/2022 05:03, Don Y wrote:
    Any preferences/suggestions for displaying "expected waveforms" in support >> materials?

    Personally I prefer black or clearly distinct coloured lines on a white background (and not too thick). Then I have normal colour vision.

    Blue/Green and Red are best not used at the same time for this reason.

    Excel default XY graphs are the opposite with a default line drawn by a three year old with a wax crayon in random pastel shades that quickly look all alike.
    I have some datasets which can crash it completely.

    Yeah, color is a big mess. Too often used (abused) by folks who think
    "more is better" (more colors, more typefaces, etc.).

    I personally prefer three colors -- background, foreground and emphasis.
    In this case, foreground would be the graticule while emphasis would
    be the "trace".

    But, you also have to consider layering (not important when foreground
    and emphasis are same color); do you want the trace to slip *under*
    the graticule? Or, ride *over* it? (given that there is usually not
    an alpha channel)

    [Of course, how you draw the graticule can make this better or worse]

    I see white traces on black backgrounds, black traces on white backgrounds, >> graticule present, graticule absent, etc. Some of this is likely related to >> the nature of *paper* documents and the fact that color doesn't *tend* to
    be reproduced in copies.

    Online publications increasingly encourage graphs in colour as opposed to lines
    in every more complex mono combos of ... .-.-. ._,_. etc.

    If I have to rely on color as a differentiator, then I also employ some
    other "encoding" method -- e.g., "texture"/fill. Because that communication channel can quickly get overloaded/overtaxed, it encourages you to think
    about how *much* you try to present in a shared frame.

    [Can you distinguish two "dashed" lines in close proximity? Is that '.' part of the '.-.' line or the '...' line? When did they cross?]

    These are interactive "documents" so the user has some control over what
    is displayed; I'm debating how much control he should have over HOW it
    is displayed! (at an extreme, I can emulate a 'scope and let him dick
    with gain, timebase, position, etc. as it's a "solve once reuse often"
    sort of problem)

    But does it help him see the detail. I can see maybe altering the timebase or trigger point might be useful sometimes.

    I think being able to interact with the presentation lets the viewer/user manipulate it to expose what *he* wants to see. (that seems to prove out, empirically)

    E.g., if I were to present a trace of the power-up sequence for my PoE PDs, there's lots of sequence information encoded in the trace but you'd have
    no idea which part of the sequence was of interest to the viewer; what to highlight in your presentation.

    Think about how you use a 'scope when troubleshooting... most probes are verifying things more-or-less "look right" (to a first order approximation). But, when you find something that looks "off", you start to explore the waveform in more detail -- focusing on particular spots that "look funny".

    And, if you're using the waveforms to try to understand a circuit or a technology, then what you might want more detail on is anyone's guess!

    Goal, however, is to make it easy for him to see what he *needs* to see
    and not distract him with the UI...

    I favour a diagram that illustrates the point you are trying to make and optimised to show whatever the feature is.

    Yes. But if that means multiple "shots" of different parts of a
    single waveform, do all of those additional presentations make it
    easier for the user, or harder (as now he has to figure out which
    is most helpful to him -- if any).

    I think the "virtual 'scope" approach is going to be the winner.

    I mocked up a little demo for colleagues so they could tinker
    with colors, Z-levels, etc. There was no clear winner in terms of
    color (possibly because I required a 24b RGB value so anything
    other than white, black and the three primaries or secondaries
    was impractical -- might as well have used 3 bits!).

    [I'll enhance the demo with a color picker to verify that color
    was NOT significant.]

    The comments I got were mostly concerned with the "controls"
    that I made available. For simplicity, I just opted for sliders
    to control scale and position/offset. My thinking was that
    you'd want *magnifiers*, of sorts.

    But, the magnifier needs, also, to be "calibrated" as they
    found use extracting finer *measurements* from the traces
    ("variable" just exposes the detail but doesn't lend itself
    to measurement).

    Hopes for a quick hack were obviously premature... <frown>

    But, at least I have a good direction to pursue!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to All on Sat Jul 30 18:08:48 2022
    On 7/29/2022 2:38 PM, whit3rd wrote:
    I'm told that lots of better-quality printers (and maybe scanners?) refuse to work with that pattern.

    I've had no problem scanning *checks* (have not had a need to scan
    currency). But, have encountered problems trying to *print* those
    scanned images!

    Most recently using an old LJ6p (5p?) so any mechanisms to inhibit this
    have been in place for a very long time!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)