On Fri, May 13, 2016 at 3:01 PM, Caleb Crome <caleb@xxxxxxxxx> wrote: > > > On Fri, May 13, 2016 at 1:45 PM, Ross Wille <audio@xxxxxxxxxxxxxxx> wrote: > >> Caleb, >> >> Yes, it's a Jensen JT-11P-1HPC (10k 1:1) line transformer. >> >> I have a custom isolation PC board, which includes the XLR jack, isolation >> transformer, variable attenuator, and transient protection. The board has >> separate "shield" and analog grounds. The output of this board feeds into >> a standard, unmodified Wandboard via the 3.5mm LINEIN1 jack. >> >> I'm not plugging/unplugging the Wandboard connector (well, I started out >> that way, but the results were terrible). With the transformer and the >> TVS >> diode the problem is MUCH better than it was initially. When I was >> driving >> the LINEIN1 jack directly from the signal generator plugging/unplugging >> the >> audio connector had a significant chance of making this happen. >> >> Now, the isolation board is always connected to the Wandboard. And >> plugging/unplugging the XLR connector is pretty reliable. The easiest way >> I've found to make the problem happen is by keeping everything connected >> and toggling the power switch on my signal generator repeatedly. >> > > > Ah Ha! Hint hint! Yes, not ESD, but electrical overstress -- too much > current I think. There is still some nonzero inter-winding capacitance > even in the Jensen transformer, and flipping that power switch gives a nice > big 340 V p-p (120Vrms) shove across those inter-widning capacitances & > impedances, (plus who knows what kind of currenets due to inductive > switching) and even with the protection you have, there isn't enough > protection to prevent latchup. > > >> I don't think I'm getting any ESD during my tests, although when this >> device >> gets put into service I'd expect to get some ESD when they plug into the >> XLR jack while the device is powered. (Maybe I'll tell them not to do >> that, but they're talking heads, not geeks.) >> >> Most of the time a reboot fixes the problem, but I've seen rare occasions >> when it does require a power cycle. >> >> The SGTL5000 doesn't have an external reset. It has an internal reset >> circuit which waits 8 clock cycles after power-on before it comes out of >> reset. So, a hardware reset of this chip requires a power cycle. >> > > Ah, bad on the designers of STL5000. > > >> >> There may be a way to force a software reset if I can still talk to the >> chip, but if the chip is latched up only a power cycle is going to fix >> that. >> > > Who knows, maybe not latchup then. May simply be a glitch that causes it > to stop functioning. I hadn't looked and noticed there was no hardware > reset. A friend of mine once had a similar problem and was able to force > the chip to come back to life by toggling the I2C SDA and SCL lines a bunch > of times (upon advice from the chip maker). You might have a hard time > getting Linux to give you back the pins and toggle them like GPIOs, rather > than treat them as an I2C bus. > > > > >> >> The LINEIN1 is capacitively coupled to the SGTL5000 (I assume that's >> because >> the SGTL5000 input has a DC bias on it). > > > Correct. > > >> I'm clamping +/-1V relative to >> the Wandboard's signal ground, but that's on the AC-coupled side of the >> signal. > > > Right, which should get the job done. The bias is probably something like > 1.3V or something, so your clamp should do a decent job of preventing much > negative voltage getting through. > > >> It'd be better to clamp it going into the codec as you've shown in >> your sketch. >> > > Right, but you need access to VDDA. > > >> >> You asked where the TVS diode is located. It's a ESDARF01-1BM2 on the >> custom isolation PCB and it's connected between signal and ground just >> before it goes out the cable (which is only 6 inches long) and into the >> Wandboard's LINEIN1 connector. It would definitely be better if the >> protection was on the Wandboard itself, especially after the coupling >> capacitor. >> >> No, breathing on it doesn't affect it. :-) I can run all night with a >> nearly full-swing sine wave at 1kHz and it never fails. It used to fail >> regularly when I messed with the audio connections, but now it's much >> harder to reproduce it. >> > > so, it's definitely due to the transient of connecting the signal > generator. > > Can I ask why you're using a signal generator? I've found that a good > pro-audio sound card (like RME, or any of the other pro-audio stuff) do a > much better job of creating and capturing audio signals than most lab gear > (except the audio-specific lab gear like Audio Precision, etc). > > For that matter, you can probably do just great using your iPhone with > AudioTools as your signal generator. Then you definitely won't have this > problem. :-) > > >> >> Thanks again for all your thoughts and ideas. It's close to being good >> enough, but it's not very professional for a piece of gear to stop working >> just because someone plugged in an XLR cable. >> > > No problem! I'm glad I could help. > > -Caleb > > By the way, I just found this circuit: http://www.eevblog.com/forum/projects/input-protection-question/msg123612/?PHPSESSID=cbedb3ec4d28bcfa8395e300665f2ee8#msg123612 It might not be great for audio, but gives good ideas how to make a bullet proof input. One that can be shorted to 240V and still survive just fine. > > > > >> >> -Ross >> >> On Friday 13 May 2016 13:23, Caleb Crome wrote: >> > On Fri, May 13, 2016 at 9:56 AM, Ross Wille <audio@xxxxxxxxxxxxxxx> >> wrote: >> > >> > > Hi Caleb, >> > > >> > > Thank you for your response! >> > > >> > > The LINEIN1 protection on the Wandboard kicks in at around 5 to 5.5 >> Volts >> > > and, as you pointed out, doesn't include a current-limiting resistor. >> The >> > > max-voltage range for the SGTL5000 audio input is spec'd at GND-0.3 to >> > > Vdda+0.3. I believe the Wandboard Vdda is 2.5V, so the on-board >> protection >> > > is likely insufficient to limit the input voltage to the datasheet >> specs. >> > > >> > > To mitigate this I have done the following: >> > > >> > > 1. I've isolated the audio between the signal generator and the codec >> chip >> > > using a professional-grade audio transformer having a breakdown >> voltage >> of >> > > 250 V RMS, so ground loops should not be an issue, but it might not >> > > eliminate ESD completely. >> > > >> > >> > Ah, a Jensen Transformer I assume? Those things are great. And the guy >> > (Bill Whitlock) really knows about dealing with hum issues. His license >> > plate reads MR CMRR. The DMV initially wouldn't give him that plate. >> > Until he explained that CMRR stands for 'common-mode rejection ratio' >> :-) >> > The stuff you learn at AES conventions... >> > >> > >> > > >> > > 2. For transient protection, I have a bidirectional TVS diode with a >> > > breakdown voltage of 1.0V(typ) between the transformer output and >> ground. >> > > The TVS diode meets IEC 61000-4-2 for contact discharge of 8 kV and >> air >> > > discharge of 15 kV and I don't believe its an ESD problem (see #3). >> The >> > > circuit impedance at the TVS diode is about 10 kohms. >> > > >> > >> > >> > >> > > >> > > 3. I'm working on a static mat and I'm grounded. >> > > >> > > In spite of doing all this, I still get the error. If latch-up is the >> > > culprit (which is possible) I am running out of things to try. I may >> need >> > > to add an active buffer stage to ensure the audio voltage never >> exceeds >> the >> > > voltage rails (but that'll require a new PCB design--sigh). >> > > >> > >> > Is this your custom board + wandboard, or is it the standard wandboard? >> > >> > Is it possible that the GND of the audio connector (which is what should >> > get hit first if you're plugging into the jack at the board side) isn't >> a >> > very good ground, and is letting ESD couple to some other lines? ESD is >> > icky that way. But, if you're ESD grounded, then this shouldn't be >> the >> > issue anyway. >> > >> > >> > > >> > > I was hoping to find a software recovery solution because rebooting >> and >> > > power-cycling the board are a rather drastic measures. >> > > >> > >> > I doubt that's possible if a reset doesn't recover it -- it seems to be >> > really broken if you need a power cycle. That's also a hint that it's >> > latchup causing the problem. >> > >> > >> > >> > > Thanks! >> > > >> > > -Ross >> > > >> > > >> > Looks like you've got most of it covered :-) >> > >> > Can you do some protection like this? >> > >> >> https://drive.google.com/file/d/0B0FeiEiLS9DzMVpTWm9QcDY5UHM/view?usp=sharing >> > >> > using something like a BAT54S? That should do a very good job of >> limiting >> > the voltage to the codec. but, a 1V TVS should do the job too I think >> if >> > it's placed on the wandboard. Where is your TVS diode placed? Soldered >> in >> > close on the connector of the wandboard, or floating out in space. >> But... >> > ESD just shouldn't be the problem if you're properly grounded. >> > >> > What else could be the culprit I wonder? This happens as soon as you >> plug >> > in, right? Does the problem ever happen when nobody is near by and >> > breathing on it? Or is always in response to some body coming close and >> > touching things? >> > >> > I'm kind of out of ideas without actually getting in close to it and >> seeing >> > what happens and when. >> > >> > Let me know if you can figure out any more details of when the problem >> > happens. I just think it's got to be a hardware problem, but I've seen >> > stranger things end up being software problems. :-) >> > >> > Cheers, >> > -Caleb >> > >> > >> > >> > > On Thursday 12 May 2016 14:13, Caleb Crome wrote: >> > > > On Thu, May 12, 2016 at 10:54 AM, Ross Wille <audio@xxxxxxxxxxxxxxx >> > >> > > wrote: >> > > > >> > > > > Hello all, >> > > > > >> > > > > I am doing an ALSA capture on a Wandboard Quad (i.MX6 quad core >> with >> > > > > SGTL5000 codec chip) from the LINEIN1 jack. I'm using a >> > > 4.6.0-rc3-armv7-x0 >> > > > > kernel. >> > > > > >> > > > > Sometimes when the audio glitches (for example, when I plug/unplug >> the >> > > > > audio >> > > > > cable or adjust my signal generator) the snd_pcm_readi() function >> will >> > > > > start returning -5 (EIO). >> > > > > >> > > > >> > > > This sounds like an ESD strike. (when you plug in the cable the ESD >> on >> > > the >> > > > cable wacks some electronics internally). >> > > > >> > > > See if you can ground yourself, the signal generator, the wand >> board, >> and >> > > > anything else with some ESD straps, and see if you can reproduce the >> > > error. >> > > > >> > > > >> > > > Looking at the wandboard baseboard, the linein1 jack *does* have ESD >> > > > protection diodes on it. >> > > > >> > > > Interestingly, the mic1 jack does not have ESD diodes. not sure >> why. >> > > > >> > > > This shouldn't be a software issue, because there's no microphone >> > > detection >> > > > going on in hardware -- the software doesn't know you've inserted >> > > anything. >> > > > >> > > > >> > > > Another possibility is a different type of electrical over stress. >> There >> > > > might be a large voltage between your wandboard GND and generator >> GND. >> > > > This is common, and is a result of the inter-widing capacitance on >> the >> > > > respective 'isolated' power supplies. If that capacitance is large >> > > enough, >> > > > it might be able to drive enough current into the pins to wreck up >> the >> > > > SGTL5000 until re-power. But... the wandboard's transient >> suppression >> > > > should be enough to deal with that. >> > > > >> > > > Oh, looking at the schematic again, there are TVS, diodes D36/D37, >> but >> > > > there is *no* series resistance between the connector and the codec! >> > > That >> > > > could easily be the problem -- an external signal can drive lots of >> (ac) >> > > > current in through those lines and cause latch-up. That's why you >> > > require >> > > > a power off/on to reset it. Even a hard reset won't fix latchup. >> > > > >> > > > See if your codec starts to get warm when in this state :-/ >> Definitely >> > > > damaging to the codec though. >> > > > >> > > > -Caleb >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > > >> > > > > Once this happens, the only way I've been able to recover is to >> reboot >> > > the >> > > > > computer. Calling snd_pcm_close(), snd_pcm_prepare(), >> snd_pcm_start(), >> > > > > etc. doesn't help. When in this state, running arecord returns IO >> > > errors >> > > > > as well. >> > > > > >> > > > > It's interesting that, on rare occasions, I must do a power cycle >> in >> > > order >> > > > > to recover. When a reboot is not effective I've noticed that the >> > > capture >> > > > > device doesn't appear in /proc/asound/devices. >> > > > > >> > > > > I don't believe my specific ALSA settings are important, but I'm >> > > calling >> > > > > snd_pcm_readi() with ALSA set to a sample rate of 48000, format of >> > > S16_LE, >> > > > > channels=1, frames per period of 960 (20 mS periods), and 4 >> periods >> per >> > > > > buffer. >> > > > > >> > > > > This same problem happens on two different Wandboards, so I don't >> think >> > > > > it's >> > > > > a defective board or chip. It has happened on older kernels as >> well. >> > > > > >> > > > > Any ideas? >> > > > > >> > > > > Thank you! >> > > > > >> > > > > Ross Wille >> > > > > _______________________________________________ >> > > > > Alsa-devel mailing list >> > > > > Alsa-devel@xxxxxxxxxxxxxxxx >> > > > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >> > > > > >> > > > >> > > >> > >> > > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
