| Electronics > Projects, Designs, and Technical Stuff |
| EMF pickup from amplifier in I2C line causing glitches. (Now with scope trace!) |
| << < (6/31) > >> |
| Monkeh:
--- Quote from: Starlord on July 03, 2016, 02:01:18 pm ---Because it's a product --- End quote --- Stop. You've just built a radio transmitter with no regard for what bands it tramples. Think long and hard before you sell this. |
| Starlord:
--- Quote from: Monkeh on July 03, 2016, 03:08:18 pm --- --- Quote from: Starlord on July 03, 2016, 02:01:18 pm ---Because it's a product --- End quote --- Stop. You've just built a radio transmitter with no regard for what bands it tramples. Think long and hard before you sell this. --- End quote --- Did you miss the part where I said I'm going to be adding the suggested ferrite bead filter, also used on TI's evalulation module for this amp, which they sell? |
| georges80:
--- Quote from: Starlord on July 03, 2016, 02:01:18 pm --- Because it's a product that I spent the better part of a year working on and have invested thousands of dollars into. I bet everything on it - it's a revision of an earlier design that had its own share of completely different issues but sold well enough to keep me in business, barely - and I've run out of time and money. ... --- End quote --- Regardless of whether you spent a year on it or not, you unfortunately made a poor decision to assume I2C was capable of running single ended over that kind of cable distance while being directly driven by a uC etc. I2C is a chip to chip interface and designed for single board usage or at most boards connected together in close proximity (inches not feet) without adding differential or opto isolated drivers. Regardless of how you try to convince yourself you need to make it work as it is, you will have field issues. You can't even get it working reliably with your test setup and if you think this is a product you can sell, what happens when people connect it with 10' of cable or 15' feet of cable in their deployment? What happens if they have various RF sources nearby, etc? "Anyway, it's not like I chose I2C without being certain I could make it work over long runs." Umm - well you made a big mistake there... I2C could likely be made to work, but it would NEED buffering with appropriate line transceivers to deal with the cable length and interference sources. Wrapping at least some kind of CRC/retry around packet transmission seems like a good idea as well. A design we implemented at work that is intended to sell in LARGE volumes use SPI and even though the interfaces are only inches apart we have checksum and packet retry/timeout implemented (interprocessor comms) just to be sure we can detect any performance and/or signal integrity issues and deal with them. Finally, I2C given it is ONLY (most of the time) actively driven low is a poor electrical signaling scheme when you are dealing with capacitive loads, cables and external interference. Sorry, but I'd hate to purchase your product if you didn't even have a scope before to verify what your margins and signal integrity looked like. Seems like you have designed something, built it, seems to work and you're off selling it without any verification at the electrical level. That's what I'd expect from a software engineer dabbling in hardware... cheers, george. |
| Someone:
--- Quote from: Starlord on July 03, 2016, 02:01:18 pm --- --- Quote from: Someone on July 03, 2016, 11:21:57 am --- --- Quote from: Starlord on July 03, 2016, 10:55:54 am ---I spent a year on this thing, so I've got no choice but to make it work with minimal changes. --- End quote --- Why does it have to work? --- End quote --- Because it's a product that I spent the better part of a year working on and have invested thousands of dollars into. I bet everything on it - it's a revision of an earlier design that had its own share of completely different issues but sold well enough to keep me in business, barely - and I've run out of time and money --- End quote --- You're pushing forward on some very poor designs and then asking for a free and cheap fix so you can profit. a) businesses pay for help through hiring contractors or consultants. b) there aren't any free fixes for your problems, they're going to need substantial changes. |
| Starlord:
--- Quote ---Regardless of how you try to convince yourself you need to make it work as it is, you will have field issues. You can't even get it working reliably with your test setup and if you think this is a product you can sell, what happens when people connect it with 10' of cable or 15' feet of cable in their deployment? What happens if they have various RF sources nearby, etc? --- End quote --- Well, if it barely works at 7' then it won't work at all if they try to use a 10' or 15' cable, so that would prevent them from doing that. :) But seriously... the product comes with a 7' cable, and that's what it's designed for. No more, no less. If I design an unpowered USB hub to work with cables up to 10' and it doesn't work with cables that are 25' is that a design flaw? And if they have RF sources nearby that cause the product to stop working, it's not that big a deal. If you had a circus performer wearing a suit with blinking LEDs all over it and it stopped working when he was standing next to cars with actively transmitting CB radios, would that be a big deal to them? Probably not. What is a big deal though is actually getting the suit of blinking LEDs they paid for, and getting it at a price that won't break the bank. That's not what this is, but I have actually had people contact me to construct things like that and they wanted it to cost them less than $500. Also, I should point out that in my tests, moving the speaker just one inch further away from the cable was sufficient to reduce the interference to the point where everything started working again. So thanks to he inverse square law, I can say with fair certainty that random radio transmissions would be unlikely to affect it, because they would have to be very close and/or extremely powerful. I would also ask if you think that WiFi routers are poorly designed because they stop working when a microwave is active nearby. Sometimes you have to accept interference. --- Quote ---Sorry, but I'd hate to purchase your product if you didn't even have a scope before to verify what your margins and signal integrity looked like. Seems like you have designed something, built it, seems to work and you're off selling it without any verification at the electrical level. That's what I'd expect from a software engineer dabbling in hardware... --- End quote --- And I'd hate to contract work out to you if after paying you $500 to design it and waiting a year you said "Sorry, I'm gonna need another $500 and another year to design a new revision because I made a mistake in the present design. It works well enough for your needs, but I can't in good conscience sell this to you in its present state. It's not dangerous, but this guy on the EEVBlog forum said it was bad design and I'm a bad engineer." :) PS: I -am- a software engineer dabbling in hardware. I was a software engineer for 20 years, but couldn't make a successful business out of it. The most successful product I ever had only brought in $200 a month. Then I picked up an Arduino. Six years later and I'm more in love electrical engineering than I ever was with software, making quick progress, and actually making a little money for once. As for not owning a scope, I've been working on an extremely tight budget. When you're barely making rent each month, it's hard to justify spending $400 on something that might only make the thing you have that works work slightly better. And it's also hard to justify spending $100 on a crappy old used something when you have your eye on a brand new beautiful $400 something that you might be able to afford next month, maybe. |
| Navigation |
| Message Index |
| Next page |
| Previous page |