That is not what I meant. One of the key things to being a good engineer is to recognize own limitations and ask someone more skilled in the particular domain for help instead of carrying on and digging yourself into a hole.
I recognize my limitations. That's why I came here looking for help when I ran into a problem I wasn't sure I could solve on my own in a reasonable period of time.
By that I mean an actual engineer actually looking over/helping you design your product, not you cherry-picking irrelevant bits and pieces online.
Can't afford to pay someone more talented than you $50/hr to look over your shoulder as you design a product? Then you're a bad engineer and shouldn't bother trying to design anything. Got it.
That StackExchange question doesn't consider neither the several feet of cable you are using nor the output of the power amp running parallel to your signal wires. Ever heard of crosstalk?
Sure I've heard of it. But until now, I was flying blind. I've been doing this for six years, and until a couple weeks ago I'd never even used a scope. I couldn't afford one. So, while I knew crosstalk was a thing, I had no idea if it was occurring in any of my circuits, or how serious of an issue it was. As long as my circuit worked, that was good enough for me. And after experiencing it once, it's not like I've suddenly gained the insight I need to know when and where it might crop up again so I can prevent it before it happens. Well, except in the case of this amplifier. I know now that I need that filter on the output if I'm gonna have a long data cable nearby.
Moreover, none of the answers really apply to your case - guy running serial connection over many meters but using UART not I2C, another one using USB, etc.
The guy using USB isn't using USB, he just worded it poorly.
The only somewhat relevant info on that page is that last guy pointing out the P82B96 line driver - but you didn't choose to use that anyway, so ...
Ah, but I was AWARE of it. See, I didn't just jump into this like an imbecile. I did my research, like I said. And the plan ALWAYS was that if I could not make it work using just pullup resistors, that the fallback plan would be to use one of those differential buffer chips or the P82B96 to make it work. I was certain those would work.
Of course, I was only certain because I wasn't aware of what my amplifier would be doing to my data transmission. But if I'd been aware of that, I would have implemented the filtering on it in the first place, and we wouldn't even be having this conversation because everything would have worked well enough for me with just the pullups.
If anything, you pointing to that link only shows you don't really understand what you are doing.
Gee, you think? Personally, I think that if you think YOU know what you're doing, you're the fool. Because the more I learn about his stuff the more I'm certain that I could be at it for the next 30 years and still be learning new stuff. And frankly, that's pretty awesome. I HATED software development for the opposite reason. Once I learned a language, I basically knew everything I needed to know to write any app in it. Then it just became rote. I like solving problems.
Electronics isn't software engineering where you can often "wing it" and it still works, only perhaps a bit slower or less memory efficient.
I beg to differ. I've been winging it for six years. And my stuff still works. But it may be a bit buggy. And it may fry the occasional SD card. Well, the previous version did anyway. I fixed that particular issue.
And code, like electronics, can simply not work, or crash constantly if you don't know what you're doing. One can easily write into program memory by mistake if you're not careful with your pointer arithmetic (and you're not coding on an architecture that prohibits that) and then you'll get random crashes and have no idea what's causing them. Heck, even on the Atmega where you can't overwrite program memory, you can still end up having your variables crash into your stack because you've only got 2K of ram to work with and that's a fun bug to track down since there's no way to know exactly how much RAM you're using on either end.
Physics doesn't give a damn whether you are trying to feed a family, doing it as a hobby or for profit. Either you do things properly and it will work or you don't and it will not.
Define work. Because in software, a program is considered to work even if it has hundreds of bugs just waiting to wreak havoc, and people have come to expect that in any software package. I wouldn't say a board that doesn't work perfectly in every instance is necessarily broken. Is a toy that glitches when the batteries run low instead of shutting off broken? Or did the toy maker decide that was an acceptable mode of failure for a product of that price range and purpose?
Sitting on my bench, the product worked fine. If there were any glitches, they were occasional, and barely noticeable, since they would only last for 1/60th of a second in between LED updates.
So the occasional glitches even on the bench in a controlled and pretty much ideal situation didn't actually make you wonder that something could be off with your design?
Of course I wondered what was wrong with the thing when I saw glitching on the bench. But having no scope, I had no idea if it was a software or hardware issue. So I tweaked the software, and eventually got the glitching to go away. At least 99.9% of it. The 0.1% was barely noticeable, to the point that I wasn't even sure if I was seeing it. It could have been an artifact of multiplexing in my peripheral vision. And since I was pressed for time and money, if I couldn't even be sure it was happening myself, my customers probably wouldn't notice it.
If it was glitching on the bench already, in the real world it would not work at all - as you have discovered. You cannot engineer things to barely work on the bench hoping it will be good enough. But I guess you have learned that now. There is a concept of design margin that covers this. Dave uses the "belt and braces" term for it too.
Dave also says that failures can be a good learning experience: