Waveform displays...

[Don Y]

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...

 

[Jan Panteltje]

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

 

[Martin Brown]

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

 

[Martin Rid]

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

 

[Phil Hobbs]

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

 

[whit3rd]

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).

 

[John Walliker]

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

 

[whit3rd]

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.

 

[amdx]

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

 

[Jan Panteltje]

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,

 

[Don Y]

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!

 

[Don Y]

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!