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...
On a sunny day (Tue, 26 Jul 2022 21:03:51 -0700) it happened Don Y snipped-for-privacy@foo.invalid wrote in <tbqdfg$2e90g$ snipped-for-privacy@dont-email.me:
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:
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.
Online publications increasingly encourage graphs in colour as opposed to lines in every more complex mono combos of ... .-.-. ._,_. etc.
But does it help him see the detail. I can see maybe altering the timebase or trigger point might be useful sometimes.
I favour a diagram that illustrates the point you are trying to make and optimised to show whatever the feature is.
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).
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.
On a sunny day (Fri, 29 Jul 2022 14:38:22 -0700 (PDT)) it happened whit3rd snipped-for-privacy@gmail.com wrote in snipped-for-privacy@googlegroups.com:
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,
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]
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?]
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!
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>
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.