Electronics > Projects, Designs, and Technical Stuff

EMF pickup from amplifier in I2C line causing glitches. (Now with scope trace!)

<< < (29/31) > >>

tggzzz:

--- Quote from: Starlord on July 14, 2016, 05:27:06 pm --- I got it to work.  It's glitchy when there's noise, I'll give you that.  And it's way out of spec and whether it will be 100% reliable is certainly questionable.  But it works.  And if I had only FM+ devices on there where I could use stronger pullups, perhaps it would have been immune to noise.  Or, perhaps if I had used a shielded cable it would have been immune to noise.  Or, I could have used one of several buffer chips to make it immune to noise.

--- End quote ---

Ah. This is clearly a meaning of "work" that is unfamiliar to me. I wonder how long it will be before your unique definition is recorded in dictionaries.

tggzzz:

--- Quote from: janoc on July 14, 2016, 07:26:10 pm ---
--- Quote from: Starlord on July 14, 2016, 04:32:34 pm ---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.
--- End quote ---

 :palm: 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? 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.

--- End quote ---

Just so.

Engineering is 10% thinking about how things will work, and 90% about thinking about how they will fail. And then avoiding the failure modes.

Hackers and the less competent engineer-wannabes never quite seem to realise that.

Starlord:

--- Quote from: janoc on July 14, 2016, 07:26:10 pm ---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.
--- End quote ---

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.



--- Quote ---By that I mean an actual engineer actually looking over/helping you design your product, not you cherry-picking irrelevant bits and pieces online.
--- End quote ---

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.


--- Quote ---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?

--- End quote ---

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.


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

--- End quote ---

The guy using USB isn't using USB, he just worded it poorly.



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

--- End quote ---

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.



--- Quote ---If anything, you pointing to that link only shows you don't really understand what you are doing.

--- End quote ---

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. 


--- Quote ---Electronics isn't software engineering where you can often "wing it" and it still works, only perhaps a bit slower or less memory efficient.

--- End quote ---

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. 


--- Quote ---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.
--- End quote ---

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? 


--- Quote ---
--- Quote ---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.
--- End quote ---

 :palm: 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?

--- End quote ---

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.



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

--- End quote ---

Dave also says that failures can be a good learning experience:

Monkeh:

--- Quote from: Starlord on July 14, 2016, 08:28:13 pm ---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?

--- End quote ---

Work: Function without error across the entire expected and acceptable range of operating conditions.

Discharged batteries are outside the acceptable operating conditions. Presence of a radio transmitter in a licensed band is not outside acceptable conditions, it is inevitable. If your product craps itself when someone walks past with their phone ringing, it does not work!

No, you can't test every possible source of interference, but you can test quite a range easily enough with items you have at home, and you can make a serious effort to protect it against interference. Alternatively, you can just shove a 'high' speed single ended interface down a bit of unshielded cable and hope for the best.. and receive the worst.


--- Quote ---I know now that I need that filter on the output if I'm gonna have a long data cable nearby.
--- End quote ---

No, you need that filter, and a reasonably proven working example for that matter, on the output whenever you're going to have a cable attached to it. It is not about it interfering with your own product, it's about everything else it interferes with!

dmills:

--- Quote from: Starlord on July 14, 2016, 01:44:58 pm ---And do WHAT?  I don't have a degree in electrical engineering.  I'm all self-taught.  Nobody would hire me.  And my software engineering skills are for the most part 20 years out of date.

--- End quote ---
I also lack a degree and my software skills are mainly C and old C++ with a few assemblers thrown in (So also 20 years out of date to some ways of thinking), it has not stopped me being hired as lead hardware engineer (Who ends up doing a disgusting amount of software).

Task domain knowledge is the key to getting jobs without a degree, by which I mean that 'electronics hobbyist' is unimpressive, electronics hobbyist who understands diving or soil mechanics or concrete engineering or hydrology or broadcast TV workflow or fleet logistics or whatever is potentially very interesting to the right sort of company (The dirty little secret is that figuring out what problem needs solving is often harder then designing something to solve it).

I would second the comment that design is less about the ways it can work then about eliminating the ways it can fail, and EMC is not exactly an area that gets no discussion, you can never ignore physics, them laws need no court. 

Regards, Dan.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod