ESS Sabre32 Reference Board S/PDIF Locking Problem

Status
Not open for further replies.
Hello all!

I have a reference board from ESS that I got some time ago (I'm not sure when; it's been at least a few years). Recently, I've noticed a problem where it seems to briefly drop S/PDIF lock (for maybe half a second or a bit less) a few times, each time I power it on. It doesn't usually happen immediately after power-on. Usually, it happens after maybe 40-50 seconds, and then maybe 2-3 times again thereafter at what appear to be random intervals.

I tried doing some research on this issue, and have found some discussion on a "warm up" period associated with S/PDIF locking. However, this seemed to concern behavior on various third-party designs. I never found any mention of this behavior with regard to a reference/demo board from ESS.

So, I guess I'm wondering, have others observed such a behavior? If so, is there anything I can/should do to improve the situation? Aside from that, I'm wondering about troubleshooting tips, and what generally I should be looking for/thinking about that would lead to this sort of problem. I'm worried that maybe something broke somewhere, but I'm not sure what is the most likely culprit.

Thank you in advance for any help with this issue (and for taking the time to read)!
 
Just some thoughts never having even seen one... have you tried the DAC with other equipment to see whether the problem is consistent ?

Always check for common issues such as dries on anything such as connectors and sockets, and on heat producing components such as regulators. I'm assuming it uses a transformer coupled SPDIF input. Check that for dries too.

One issue that appears now and again on the forum is the fact that there are Different SPDIF output levels in use and using the wrong one might just work but be marginal.

All very vague and non specific I know but maybe some pointers in there.
 
Just some thoughts never having even seen one... have you tried the DAC with other equipment to see whether the problem is consistent ?

Always check for common issues such as dries on anything such as connectors and sockets, and on heat producing components such as regulators. I'm assuming it uses a transformer coupled SPDIF input. Check that for dries too.

One issue that appears now and again on the forum is the fact that there are Different SPDIF output levels in use and using the wrong one might just work but be marginal.

At the moment, I'm stuck with the S/PDIF output from a soundcard (ESI Maya) or the onboard output on my computer's motherboard. I tried both of those, and observed the same behavior in both cases.

I just reflowed the jack and various resistors and capacitors that I estimated to be in the datapath for S/PDIF input to the Sabre, just in case. The overall behavior appears to be the same afterwards. It seems to often unlock after around 45-55 seconds after power-on and playback of something. If I let it continue, it'll typically unlock another 2-3 times, roughly around that interval thereafter.

I don't see a transformer on the input. I see an IC, though I can't identify which it is as it's a SOT-23 and doesn't have conspicuous enough markings. I can't find a schematic for this thing, unfortunately. If I had to guess, I'd suspect it's a comparator. Nearby are a few resistors and capacitors.

That's a good thought on the signal level. I've used this board before in this configuration (i.e. with this computer/sound card), and I don't recall having this problem in the past when doing so. However, perhaps in the past I chalked it up to glitches with the sound card. I remember having intermittent blips before, but I don't recall them being as long in duration or regularized.

All very vague and non specific I know but maybe some pointers in there.

Well, very helpful nonetheless. Unfortunately, I don't have most of the equipment I'd otherwise use to diagnose the problem. I also have limited experience with this sort of issue, so almost any advice and ideas are beneficial and much appreciated 🙂. I wish I could afford a decent oscilloscope; the (rather old) one I used to use died 🙁.
 
Hmmm. Using it on two sources rules anything out on that score (apart from levels of course if both were the same).

Two threads I remember on levels,
http://www.diyaudio.com/forums/digital-source/205307-nad-c541i-cd-player-coaxial-out-problem.html

And the link from that one,
http://www.diyaudio.com/forums/digi...dian-500-transport-arcam-bb2.html#post2386313

I really don't know what to suggest. Could there be a clock error (slightly incorrect frequency) on the DAC causing it to have poor lock ? You would need a frequency counter and full circuit details to begin to investigate that one.
 
Here's one place I found some discussion of 'warm-up' and S/PDIF locking behavior: https://hifiduino.wordpress.com/category/test/

ah this one, well, if you didn't change setting of DPLL or didn't install microwave/AC router next to your DAC than it doesn't explain your troubles, you might got worse quality oscillator which start making troubles after few years of working, or one of your psu circuit failing but there's too much variables to look at and without measuring things and looking at schematics it'll be pretty difficult to suggest anything
 
Thank you, guys, for your help. I know it's not a lot to work with; I wish I had more 🙁

I did check out ESS' site and it seems they now have posted documents detailing schematics and board layout:

Schematic: http://www.esstech.com/PDF/Sabre_8_2Channel_64PIN_V3_SCH.pdf

Layout (Top): http://www.esstech.com/PDF/Sabre_8_2CH_64PIN_Ver3_Top.pdf

Layout (Bottom): http://www.esstech.com/PDF/Sabre_8_2CH_64PIN_Ver3_Bottom.pdf

I could try ordering a new oscillator if you think that might help. I guess as a side note, if I swap the current one (40MHz) for 80 or 100MHz, it'll take a 192KHz input (it maxes out at 96KHz currently w/ 40MHz).
 
I wouldn't replace parts or modules in hope tbh.

Faced with something like this the first checks would be to both measure and scope all the power rails (never assume anything is OK until proved to be so) and the rails are the first checkpoint. You could then try and look at the spdif signal from the comparator output and see if anything looked amiss, such as high frequency noise or hash.

Another 'engineer mode' 🙂D) check would be to dab a finger around the 40MHz crystal and see how easy it was to pull off lock. There are two caps, C152 and C153. Tagging something like a 2.2pf across one or both might give some clue as to whether things are marginal around there. Ideally a frequency counter would be used to confirm the exact osc rate.

Its not easy diagnosing faults like this although typically the large IC's will not be the problem.
 
That's a good idea on checking the power supply. At the moment, I get 12.3V for both + and -. As I recall, this matches what I found back when I originally got the board.

I wish I could look at the comparator output. I unfortunately don't have a scope, and can't afford to buy one at the moment. Sigh 🙁. I can try the other tests, though. I'll have to go get a 2.2pF (or thereabouts) cap.


Regarding XO replacement, I mostly contemplated it because I'd been considering swapping it out anyway in order to have 192KHz Fs support. So, if it was thought that it may help the situation, I'd probably stop putting off the operation and finally swap it 😛
 
Adding the caps is really just to 'pull' the oscillator and see if it makes things better or worse... which would be a good clue. I wouldn't like to say whether swapping the oscillator would be wise or not at this stage tbh.
 
First of all, thank you again Mooly for all your help. I deeply appreciate it.

I took a look at the board again, and the schematic, and there's a bit of a snag. My board has a 4-pin SMD XO on it instead of a 2-pin through-hole. I can't find any capacitors that look equivalent to those marked C152/C153 on the schematic, either on the top or bottom of the board. It also looks like the output (Pin 3) goes straight to the XO input (Pin 24) on the Sabre, and nothing appears to be connected to Pin 23 ("XO"). So, a major break from the schematic. Weird.

In light of this, how should I try to perform the prior-mentioned diagnostic procedure? Sorry if this is a really newbie (i.e. tedious) question. I have a limited understanding of the mechanics at the moment, so am not sure about these things >_<

Re: Oscillator. OK. I understand. kukynas mentioned that maybe the XO had gone bad, but didn't indicate the likelihood of that possibility. At some point, it would be nice to swap in a 100MHz *shrug*. However, I certainly don't want to make the problem worse.
 
Last edited:
It does sound like you have a different (but how different I don't know) version of the DAC. It appears the 4 pin device you see is actually a complete oscillator in itself and not just a crystal as shown on the diagram. That means the simple tests outlined wont work because you can't get 'inside' the device to pull the frequency. As we can't measure the frequency and use a scope to look at the output, replacement would be the only way of proving it. I'm not sure either how standard the pin outs are for these oscillators... you would need to check before ordering one. And check the frequency is still 25Mhz as per the original crystal.

You could try freezer spray on the osc, just a few drips to see if it stopped it going out of lock. Freezer is expensive stuff, you can use an air duster can by inverting it and dripping the stuff out. Not quite as cold (freezer spray gets to -50C) but good enough at -30 or so.

I'm not qualified to say whether the DAC could accept other master clock frequencies such as the 100Mhz you mention. Only the designer of the unit could advise on that.
 
Saw these lines in ES9018 Application Note, you may check.
 

Attachments

  • ess spdif termination resistor - error.jpg
    ess spdif termination resistor - error.jpg
    35.5 KB · Views: 135
It does sound like you have a different (but how different I don't know) version of the DAC. It appears the 4 pin device you see is actually a complete oscillator in itself and not just a crystal as shown on the diagram. That means the simple tests outlined wont work because you can't get 'inside' the device to pull the frequency. As we can't measure the frequency and use a scope to look at the output, replacement would be the only way of proving it. I'm not sure either how standard the pin outs are for these oscillators... you would need to check before ordering one. And check the frequency is still 25Mhz as per the original crystal.

You could try freezer spray on the osc, just a few drips to see if it stopped it going out of lock. Freezer is expensive stuff, you can use an air duster can by inverting it and dripping the stuff out. Not quite as cold (freezer spray gets to -50C) but good enough at -30 or so.

I'm not qualified to say whether the DAC could accept other master clock frequencies such as the 100Mhz you mention. Only the designer of the unit could advise on that.

For the past couple days, the board has settled into a behavior of dropping lock 2 times before going stable, following power-on. I'm not entirely sure what to make of that. I think I will try the freeze-spray idea, though I'm not sure if the limited extent to which the board is unlocking will make it difficult to influence by freezing.

Apart from that...it looks like in most regards the board schematic is the same or very similar to that of the other board. Enough so that I didn't even notice the difference between them at first. It still has X1 and X2, just no X3. However, I'm going to need to double-check the S/PDIF input, per rredline's observation (thank you, rredline, for pointing that out!).

I thought to use 100MHz as it is one of the most popular MCLK frequencies used with the Sabre, and ESS indicates it as a standard (supported) rate. A lot of the commercial implementations appear to use 100MHz. I'm thinking about ordering a new oscillator, along with replacement regulators and a comparator. I can apparently replace most of the parts for about $5, so it might be worth just doing so.
 
Its always best to at least try and find the problem by whatever means first rather than just replacing parts. You should at least get confirmation that no changes are required to the board if you want to use another clock rate. Perhaps a jumper or shorting link etc... just guessing at possibilities but you need to be sure.

And definitely worth looking at the info rredline turned up too.
 
Its always best to at least try and find the problem by whatever means first rather than just replacing parts. You should at least get confirmation that no changes are required to the board if you want to use another clock rate. Perhaps a jumper or shorting link etc... just guessing at possibilities but you need to be sure.

And definitely worth looking at the info rredline turned up too.

Okay. I'll keep trying to track down the issue if I can, then. The main problem I'm facing is a lack of tools for diagnosis. No scope, no counter, and so forth so that limits my ability to hunt down the problem 🙁

However, I will try the freeze spray and check out the input resistor first. If there is anything else I should try, I'm happy to do so. I want to do everything here in a sensible fashion; just finding myself at a bit of a loss as to what to do given the constraints I'm working with >____<
 
Its a very difficult problem to diagnose unfortunately. The clock and looking at the data coming into the board (and this 75 ohm mod) are the first suspects. The rails have to be correct with no ripple or anything like that. Beyond that and without dedicated specialised test gear (gear way beyond a scope and simple freq counter) it becomes guesswork.
 
This is the (somewhat) official Coax input schematic for ES9018 that's known to work.

IC2 = LMV7219 (SOT-23)
VDD = 3.3V
R13 = 75 Ohm

You may replace the IC2 if you suspect that it may be defective. You may also increase the DPLL value if you can access the DAC chip's firmware registers.
 

Attachments

  • ES9018 SPDIF input schematic.jpg
    ES9018 SPDIF input schematic.jpg
    10.3 KB · Views: 110
The board has a USB input that can be used for firmware updates by way of control software developed by ESS. Unfortunately, they don't have it posted on their site anymore and I have no idea how to obtain it. I think it's called "Sabre32_GUI" or something of that sort. It would probably be helpful for diagnosis as, among other things, one can use it to adjust DPLL settings. Wish I had a copy of this software 🙁
 
Status
Not open for further replies.