EEVblog #224 red green blindness problem

[PetrosA]

I've never heard of color blind people not being allow to work as electricians here in the US. I have red-green issues like Hero999 and I have to be careful with black and green wires in low light conditions, depending on the manufacturer. For some reason we haven't adopted the green/yellow stripe standard for ground wires in N. America nor is there a "safety" green used for insulation (I would be very much in favor...).

I am now on my third LED flashlight, not because the old ones stopped working, but because the CRI keeps getting better and that's important in my work.

Edit to add: I have heard that up to 15% of men have some degree of red/green deficiency. It's always been something I've tried to be aware of in any design work I did.

[ciccio]

Have you tried looking at some OLD resistors to see if the problem is as pronounced?

Well, the older resistors I have in stock are usually bigger in size (1/2 W against 1/4 W), and the body color is darker.
The new ones have less defined color stripes (orange = red, etc), and I believe that the paint thickness is very small, so colors are a little "smeared", but everything goes OK with more lighting and a little magnification..

Thank for the suggestions.
Best regard

[robrenz]

I don't think you can change the colours. They are matched to the front panel and probe colour coding.

Dave.

Use channel 1 and 3 (yellow-blue) instead of 1 and 2 (yellow-green)

[Excavatoree]

Two random and late thoughts:

When I designed harnesses for school busses, we had to specify that the wires be marked with numbers in addition to the color codes.  (even in the case where the number wasn't a circuit number, but merely a color indicator - 55 is red, for example.

The CAD program PRO-E uses red and green to indicate sides of planes - one of my co-workers had to change his colors, as he couldn't distinguish between the two.

[saturation]

Its possible to help some variants see better with color shifting lenses:

http://www.colormax.org/

YMMV, but what have you to lose if you have RG deficiency?

[baljemmett]

The CAD program PRO-E uses red and green to indicate sides of planes - one of my co-workers had to change his colors, as he couldn't distinguish between the two.

When I tried gEDA's schematic capture program a while back, I'd been struggling for ages to get wires connected to symbols properly until I noticed it showed a little red dash at the connection points -- it was practically invisible to me against the black background, so I'd been trying to wire things up to the wrong places!

(Now, I would have researched the commands I needed to give it to change the colours to something more compatible with my eyes, except by that point I'd also given up on trying to get useful HP-GL output from it too so just switched packages...)

[Bored@Work]

(Now, I would have researched the commands I needed to give it to change the colours to something more compatible with my eyes,

You are glad you didn't. The gEDA developers made a classic mistake, thinking every user is a programmer ... Colors are changed by changing a script that is executed at startup by gEDA's build-in scripting language interpreter. Located in some non-obvious  place.

What is even worse, they settled on an obscure scripting language, Scheme. Yes I know, Scheme give long beard CS types and users of a certain editor a hard one. But really, for PCB designers? People who just want to do their PCB, without a master in CS just to change the color of that thing. I am sure you can do wonderful things in the startup script with that scripting language, and it is sooooooooo flexible, but who the f... wants that?

[Zero999]

I have red-green issues like Hero999 and I have to be careful with black and green wires in low light conditions, depending on the manufacturer.

My colour deficiency is nowhere near that bad.

By the sounds of it you lack green receptors alltogether or they're reduced in number. I don't have any porblem with colours in real life, it's just I fail some colourblindness tests which I find frustrating because people think I'm worse than I am.

[baljemmett]

(Now, I would have researched the commands I needed to give it to change the colours to something more compatible with my eyes,

You are glad you didn't. The gEDA developers made a classic mistake, thinking every user is a programmer ... Colors are changed by changing a script that is executed at startup by gEDA's build-in scripting language interpreter. Located in some non-obvious  place.

Aye, there was some other setting that I'd changed similarly.  When I found out that was the only way to change the colours I couldn't help but think someone had perhaps missed the point of a GUI...  Seriously, surely it's obvious that the right way to do this is a nice colour chooser widget of some sort next to a small example section of schematic so you can see how your selection will work out.  (Yeah, I know, 'patches welcome', etc.)

Yes I know, Scheme give long beard CS types and users of a certain editor a hard one.

Heh; as a clean-shaven CS type and user of the other certain editor, I had much the same reaction.  I mean, I may be a pervert right enough, but I'm not sick! 

[Bored@Work]

(Yeah, I know, 'patches welcome', etc.)

My experience with submitting large, non-trivial patches to open source projects is that they are usually not welcome and are rejected. No, I haven't tried to submit a patch to gEDA, so I don't know if they are the exception.

If you are lucky an open source project rejects your large patch but kindly allows you to resubmit it after you jumped through all kinds of hoops. Like signing a contributor agreement, porting your code back and forth to development, staging, testing and whatnot branches, all at the same time, and insisting you follow coding rules which, on the other hand, aren't at all taken serious by the regular contributors in the existing code base.

user of the other certain editor

Also known as the 1TE, the one true editor.

[alm]

While this sucks from a user experience perspective, I can understand the developer side as well. You start by implementing support for configurable colors. For testing, you just write some scheme by hand. You'll implement the color configuration UI later, except that something more important came up. For most users, a dialog for configuring colors isn't exactly at the top of their wish list. Open-source projects by gEDA have limited resources, both in time and motivation.

My experience with submitting large, non-trivial patches to open source projects is that they are usually not welcome and are rejected. No, I haven't tried to submit a patch to gEDA, so I don't know if they are the exception.

If you look at the bigger picture, i.e. that the stability and maintainability of the whole code base is more important than a single feature, they may have a valid point there. Merging random patches without regard for quality or consistent style is not a good long-term strategy. It's very hard to evaluate someone else's work if they just replaced an entire subsystem. Small incremental changes are much easier to verify. Of course in some cases the answer is politically motivated, i.e. "I don't like the idea and hope you go away".

[baljemmett]

While this sucks from a user experience perspective, I can understand the developer side as well.

Oh, indeed; with my professional hat on it's perfectly understandable -- although since I write commercial closed-source stuff I don't have the luxury of leaving UI out of a release because I didn't have an itch to scratch (but unless the UI is going to influence the implementation significantly, it doesn't get written until later.)  That's not such a problem in the open-source world where 'release' is a rather more nebulous concept.

(I should probably add that I wouldn't have found messing with the config file and playing guess-some-colours-that-will-work to be a huge problem, per se, but since I couldn't find a working lash-up of print configuration and filters to get a decent A3 plot out of it I didn't see much point in sticking around -- and it was anyone's guess which package was at fault with that issue.)

[baljemmett]

My experience with submitting large, non-trivial patches to open source projects is that they are usually not welcome and are rejected. No, I haven't tried to submit a patch to gEDA, so I don't know if they are the exception.

Thankfully I think my experience has been with either small, trivial patches or more-receptive projects; mind you, in some cases the patches I sent just stung the relevant maintainers into doing a better job themselves.  Either way, mission accomplished!  I spent several years watching Wine development though and, well, *shudder*...

(Not that I can claim to be much better.  I think a project that I allegedly maintain has a couple of patches that have been rotting in the queue for a year or two now; really must do something about that before its tenth anniversary.)

user of the other certain editor

Also known as the 1TE, the one true editor.

Good man!

[Zero999]

My experience with submitting large, non-trivial patches to open source projects is that they are usually not welcome and are rejected. No, I haven't tried to submit a patch to gEDA, so I don't know if they are the exception.

If you are lucky an open source project rejects your large patch but kindly allows you to resubmit it after you jumped through all kinds of hoops. Like signing a contributor agreement, porting your code back and forth to development, staging, testing and whatnot branches, all at the same time, and insisting you follow coding rules which, on the other hand, aren't at all taken serious by the regular contributors in the existing code base.

Or you could cut the BS and create your own fork. If it's popular enough, the changes will be eventually be accepted by the project.

[Excavatoree]

Or you could cut the BS and create your own fork. If it's popular enough, the changes will be eventually be accepted by the project.

You mean create one's own "forking version?"


(sorry, I couldn't resist)