PCM81 - AES Problem

[Grappa]

Hi all,

Pulled out the venerable PCM81 today as I'm messing around finalising my setup after implementation of my shiny new and rather fantastic RME UCX II.

Connected it via AES (which I've never done before) and immediately saw the word clock sync EXT: XLR Pro 48 on the display in Control. Great I thought.. this is going to be a walk in the park. Looked at the Fireface USB settings and AES was showing as 'No Lock'.. oh.. signal going in fine but sadly nothing coming back out when testing.

Plugged it in via SPDIF and got the WC lock and Sync immediately. Don't want to use SPIDF however as I have the Kemper plugged in..

Swopped the cables (they are 75ohm AES) and no change.

Am I doing anything stupid or do we have a problem Houston?

Had a Quick Look under the bonnet after reading the service manual (which unfortunately states the test for AES is sort of plug another device into it and see if it works!). Can't see anything obvious around the AES output components, board or IC's..

Is there anyone nowadays who can inspect/repair these things?

Si

[Hugh Robjohns]

Assuming you've configured the AES out correctly and it really is dead (it would be unusual, but not impossible), then you can still use the PCM81's S/PDIF connections to/from the RME's AES3 ports with nothing more than adapter cables — XLR pin 2 to RCA phono tip, XLR pin 3 to RCA phono sleeve, XLR pin1 to cable screen (isolated at RCA end).

Technically, its all wrong... but as long as the cables are shortish it will work just fine.

[sonics]

Technically, its all wrong... but as long as the cables are shortish it will work just fine.

Oooh, I do love it when Hugh talks dirty!

[Grappa]

Assuming you've configured the AES out correctly and it really is dead (it would be unusual, but not impossible), then you can still use the PCM81's S/PDIF connections to/from the RME's AES3 ports with nothing more than adapter cables — XLR pin 2 to RCA phono tip, XLR pin 3 to RCA phono sleeve, XLR pin1 to cable screen (isolated at RCA end).

Technically, its all wrong... but as long as the cables are shortish it will work just fine.

Thanks Hugh. I may have to take that approach..

Ironically after your post I dug into the UCX manual again to see if I could spot any errors on my part and noticed that RME have designed the AES interface to support your suggested workaround so we should be good.

Si

[Hugh Robjohns]

'Designed' is a bit strong....

The committee that invented the AES3 and S/PDIF formats deliberately made them (broadly) compatible — at least from a data coding point of view. Their electrical interfacing is different to suit different applications, but not wildly different and they can be persuaded to work together quite happily over short distances before cable effects become significant.

RME have just embraced that option for user pragmatism...

[Grappa]

'Designed' is a bit strong....

The committee that invented the AES3 and S/PDIF formats deliberately made them (broadly) compatible — at least from a data coding point of view. Their electrical interfacing is different to suit different applications, but not wildly different and they can be persuaded to work together quite happily over short distances before cable effects become significant.

RME have just embraced that option for user pragmatism...

I'll take it as a win if it works and solves the problem I currently face. Albeit in honesty part of me still wants to see if I can get it to work 'properly' but that's just the way I am..

Thanks again for your help.

Si

[Grappa]

So somewhat disappointingly the S/PDIF hack doesn't seem to work for me.

I get an inbound lock on the PCM @ 48k 'Prof' on the S/PDIF input but the output sounds like a dolphin on crack (not confirmed but you catch my drift).

The RME shows variable inbound lock at 48k on the AES port - it drops in and out intermittently.

Interestingly the PCM has the ability to report further information on the status of the digital input and there is a parameter entitled 'confidence' which iterates upwards when the S/PDIF is connected using the adaptor leads into the AES3 on the RME. It stays solid at '0' when using 'proper' S/PDIF in/out from both units.

As an aside I've metered the leads and cannot find any issue with the wiring - it is as per the diagram in the RME manual and Hugh's suggestion.

How frustrating. Any ideas?

Si

[Hugh Robjohns]

What clocking arrangements have you set up between the Lex and the RME?

[ajay_m]

If it nearly works you may care to try a short piece of cat5/6 networking cable which is designed to preserve the signal without introducing significant reflection artifacts. Looking at the spec a 110 ohm impedance is specified and cat6 is 100 ohm which seems close enough. 1 or 2 metres ought to work.

[Hugh Robjohns]

...try a short piece of cat5/6 networking cable which is designed to preserve the signal without introducing significant reflection artifacts.

Er... not really. It's a bit more complicated than that.

It's the interface between cable and device that causes signal reflections (amongst other things). All cables have a characteristic impedance which is determined by their physical construction and the materials used. By terminating the cable with the same impedance you can create a 'transmission line' which is an efficient way to pass high frequency signals.

If the termination impedances are significantly different to the cable's characteristic impedance then some signal will be reflected back down the cable, interfering with it and degrading the output. In extreme cases this can make the digital output vorrupt or even unrecoverable.

Looking at the spec a 110 ohm impedance is specified and cat6 is 100 ohm which seems close enough. 1 or 2 metres ought to work.

AES3 is specified to use cable with a characteristic impedance of 110 Ohms, basically because that us the common impedance of typical mic cables — although there is actually quite a wide variation! The designers were trying to make AES3 easy and familiar to use... but actually, spec'ing mic cables was pretty daft in hindsight!

And yes, Cat5 cable is nominally 100 Ohms and can be used quite happily for AES3. I use it a lot to convey 8 channels of AES between gear (and its a lot easier to wire into D-subs and patch using RJ45s).

S/PDIF and AES3-id are specified to use 75 Ohm cable, and there are inline 'baluns' to convert between unbalanced 75 and balanced 110 Ohm systems.

However, where the cable length is less than 2 metres or so, the moderate impedance mismatch doesn't normally cause a problem, and I've been connecting S/PDIF into AES3 (and vice versa) with simple bodge leads for decades with very few problems.

Longer cables benefit from using pukka balun converters.

So that's all a long-winded way of saying I highly doubt the cable is the problem here. My money is on either a silly clocking issue, or a defective digital interface in the Lex.

The other possibility, which I've only come across a couple of times, is a ground-loop over the digital connection (usually caused by a link between pin1 and pin3 in the AES XLR).

You don't hear hums or buzzes with digital ground-loops. Instead the unwanted ground noise essentially modulates the digital data, corrupting it, often to the point where it breaks down.

[ajay_m]

I don't disagree at all, and in general a short piece of wire ought to work just fine, because both transmitter and receiver ought to terminate at the same impedance, but I have seen the odd scenario with digital signals where the receiver expected the slew rates to be within certain limits and when receiving a 'perfect' signal as opposed to through coax or twisted pair, where the rise and fall times have been 'tamed' to a certain extent, the receiver failed to accurately decode the signal. It's a long shot, I agree, and the issue is much more likely to be clocking or something like that. And I profess to having only used SP/DIF over coax and optical and not AES, so I certainly bow to your vastly superior experience

[Hugh Robjohns]

...I have seen the odd scenario with digital signals where the receiver expected the slew rates to be within certain limits and when receiving a 'perfect' signal as opposed to through coax or twisted pair, where the rise and fall times have been 'tamed' to a certain extent, the receiver failed to accurately decode the signal.

Yes. I've seen that too, but only with long and poor quality cables where excessive cable capacitance reduces signal bandwidth, rounding off the pulses and causing massive jitter.

[ajay_m]

Interestingly the £5 Pico pi has sufficient horsepower to decide s/pdif and I assume AES as I understand the basic data framing is identical. There's an open source project if you Google. This means it's possible to build a cheap little box that can troubleshoot connectivity issues by the looks of it.
Today the pico 2 was announced. I pre-ordered 5. It has twice the memory and a faster processor and more 'pio' blocks. These enable it to process very fast bitstreams e.g audio or even synthesise video in realtime. It will be possible to build some very low cost gadgets around these, for example a direct digital to SD card recorder.

[Hugh Robjohns]

...s/pdif and I assume AES as I understand the basic data framing is identical.

The frame structure, word clock sync pulses, and audio data packing, validity and parity flags are identical between the two formats. The channel and status bits have slightly different interpretations... but few systems bother much with them anyway.