DIX4192

Hi, Max,

Terribly sorry for the delay in getting back to you. I have asked my colleague to look into this for you.

-d2

Hi Don,

thanks, I am happy to hear that. Meanwhile I will do some more tests.

Best regards,

Max

Hi Don,

are there any news regarding this topics? I am especially interested in point two, the 'LOL' option issue.

Best regards,

Max

Hi Don,

still no news regarding the topic above? I really hope that you can give me some more news regarding that problems.

Best regards,

Max

Hi Don,

it's a while now, since I pushed these topic (I had some vacation meanwhile). Are there any news regarding it?

Even a: "We do not reccomend to use LOL option that way", would help me.

Best regards,

Max

Hi, Max,

Sorry for the delay. We've been swamped with folks being out on vacation, etc. Let me escalate this again on your behalf.

-d2

Hi Max,

Regarding reg-15, can you please try setting Port-B (i.e unused port) as Master and then check for OSLIP error?

Regarding regx0E, in cases where the extended duration in audio-playback after clock-loss occurs, what is the read-back from reg-14? Can you please try setting 0x0E to x09 (instead of x19)? In this case the PLL clock will remain free-running, while audio is muted in the clock error case.

-Ravi

Hi Ravi,

sorry for my late response.

I tried what you proposed and configured Port-B to "Master Mode" and checked OSLIP again, but that didn't fix the error (OSILP IRQ is still there). Only way to fix that is to configure Port-A and B to not use DIR. Anything else I could try?

Regarding the register 0x0E and LOL option, I checked the register 0x14 after loss of connection (audio drop out) and it shows from time to time a biphase encoding error. Can that be the problem? Does this mean my receiving aes/ebu stream has error or is it only related to the wrong PLL clock which results in that error (e.g. wrong sampling of input stream)?

I am not sure why I should set the register 0x0E to 0x09 instead of 0x19 as the fourth bit controls the LOL option and it must be set to logical high (refering to datasheet page 42). Am I missing something?

Best regards and many thanks for your help/support so far,

Max

Hi Max,

Thanks for your notes.

I haven't had a chance to test out an EVM as we ran out of them. I should have one later this week, and will take a look at this on the bench and follow-up with you. Sorry about the delay.

-Ravi

Hi Ravi,

no problem, I am happy that you support me with this.

Best regards,

Max

Hi Ravi,

any news regarding that topic?
Regards,

Max

Hello Max,

Apologies for the delay. We have received the EVM dev kit and I will try to debug your two items when I come back in tomorrow. 

In the meantime, I have looked through your post(s) and tried to find anything that may cause these issues. 

Item #1) I see that you're using RXCKO as master clock for Port A clocks--I assume you have RXCKO enabled in register 0x0E as you mention in Item #2, assuming these 2 items are from the same application? (Finally, I'm curious what your incoming cable is, and want to confirm it's in I2S.)

Other than that, I cannot yet see any issue with your set-up. It is of note that you said "Only way to fix that is to configure Port-A and B to not use DIR", which of course defeats your purpose. Whatever it may be, at least your receiver seems to be working...

Item #2) Unfortunately, I can't see anything yet on this. When you say "nLock" error toggling, I assume you mean the DIR "Unlock" error in status register 14? Also, do you remember if the 'sometimes' biphase error had any co-dependence with your 'sometimes' unlock error and affected output? (Again, what kind of cable are you using to receive?) How crucial is it to use this loss-of-lock option? Does the toggling error go away if you try unplugging / re-plugging a few times?

Best regards,
Arnold Zhang 

Hello Max,

Can you go ahead and provide your config file as an attachment?

Best regards,
Arnold Zhang 

Hi Arnold Zhang,

regarding item #1): We are using CAT-5 twisted-pair cable, I do not understand what you mean with "it is in I2S". With incoming cable I mean the cable from the AES/EBU transmitter (also a DIX4192) device to my AES/EBU receiver (DIX4192).

To point #2), no in that case I meant the 'nLock Pin' of the device. Regarding the co-dependence of biphase error to my unlock problem, it could be that this is the cause, but I also remember that sometimes I couldn't see a biphase error but had same problems. How will the error status register bits reset? Only on read?  Or also if the error disappears?

To your last questions, we really would like to use the option as it is very fast in reconnection, but if that may cause sometimes problems we won't use it (and if you recommend to not use it as we do it, we won't do it either ;)). Last but not least, yes if I unplug/re-plug again the cable a few times, it may result in stable system again.

Here is the configuration I am using:

Transmitter:

// general configuration
{0x01,0x3E},                      // (byte 1) Power/RST:    enable all
{0x16,0xff},                         // (byte 2) IRQ Mask:    mask all irq's

// audio port settings
 {0x03,0x29},                      // (byte 1) PortA Con:    I²S, 24Bit, Master (BCLK, WCLK output), SDOUTA = DIR
 {0x04,0x08},                      // (byte 2) PortA Clk:    WCLK = clk/128 = 192kHz (@24.576MHz), clk = RXCLKO
 {0x05,0x41},                      // (byte 3) PortB Con:    I²S, 24Bit, Slave (BCLK, WCLK input), SDOUTA = mute (high-z)
 {0x06,0x00},                      // (byte 4) PortB Clk:    not used

// aes/ebu transmitter settings
{0x07,0x86},                       // (byte 5) TX Con 1:    AES/EBU TX use PortA, WCLK = clk/128 = 192kHz (@24.576MHz), clk = RXCLKO, valid bit = true
{0x08,0x04},                       // (byte 6) TX Con 2:    TX Output on, no mute, AES/EBU Output off, transmit DIT output (not RXx input)

// aes/ebu receiver settings
{0x0D,0x00},                     // (byte 7) RX Con 1:    RX Input = RX1, RX Ref clk = REFCLK, C/U buffer enabled
{0x0E,0x19}                      // (byte 8) RX Con 2:    RXCKO output disabled, clk divider = 1, auto mute enabled, pll runs free if lose of sync

 // aes/ebu receiver settings
{0x0D,0x00},                     // (byte 9) RX Con 1:    RX Input = RX1, RX Ref clk = REFCLK, C/U buffer enabled
{0x0E,0x18},                     // (byte 10) RX Con 2:    RXCKO output disabled, clk divider = 1, auto mute enabled, pll runs not free if lose of sync
{0x0F,0x22},                      // (byte 11) RX PLL 1:     P3| P2| P1| P0| J5| J4| J3| J2     => PLL_OUT (has to be) = 98.304MHz (oversample rate)
{0x10,0x00},                      // (byte 12) RX PLL 2:     J1| J0|D13|D12|D11|D10| D9| D8        => ('RX Ref clk' x J.D) / P = 98.304MHz
{0x11,0x00}                       // (byte 13) RX PLL 3:     D7| D6| D5| D4| D3| D2| D1| D0     => see datasheet page 43, (@24.576MHz J=8,D=0,P=2)

Receiver:

// general configuration
{0x01,0x3E},                      // (byte 1) Power/RST:    enable all
{0x16,0xff},                         // (byte 2) IRQ Mask:    mask all irq's

// audio port settings
{0x03,0x29},                        // (byte 1) PortA Con:    I²S, 24Bit, Master (BCLK, WCLK input), SDOUTA = DIR
{0x04,0x08},                        // (byte 2) PortA Clk:    WCLK = clk/128 = 192kHz (@24.576MHz), clk = RXCLKO
{0x05,0x41},                        // (byte 3) PortB Con:    I²S, 24Bit, Slave (BCLK, WCLK input), SDOUTB = mute (high-z)
{0x06,0x00},                        // (byte 4) PortB Clk:    not used

// aes/ebu transmitter settings
{0x07,0x0E},                        // (byte 5) TX Con 1:    AES/EBU TX use PortB, WCLK = clk/128 = 192kHz (@24.576MHz), clk = MCLK, valid bit = true
{0x08,0x04},                         // (byte 6) TX Con 2:    TX Output on, no mute, AES/EBU Output off, transmit DIT output (not RXx input)

// aes/ebu receiver settings
{0x0D,0x08},                         // (byte 7) RX Con 1:    RX Input = RX1, RX Ref clk = MCLK, C/U buffer enabled
{0x0E,0x19}                          // (byte 8) RX Con 2:    RXCKO output disabled, clk divider = 1, auto mute enabled, pll

Thanks for your great help/support!

Best regards,

Max

Hello Max,

Some questions up front regarding your set-up, please clarify for me:

Transmitter DIX4192: I'm not understanding your set-up here. Are you getting audio from DIR, and sending that through to both Port A and DIT?

Also, you are using Port A as source for DIT? Is SDINA connected to a source? But your master clock is coming from the DIR's RXCKO?
From your config:      {0x07,0x86},                       // (byte 5) TX Con 1:    AES/EBU TX use PortA, WCLK = clk/128 = 192kHz (@24.576MHz), clk = RXCLKO, valid bit = true

Receiver DIX4192: For this one, you are getting audio from DIR. Are you sending this to just Port A?  

Also, your last configuration notes say that you're using Port B, when everything is else points to Port A... please explain for me! And wouldn't this use RXCKO as receiver?  (Is the DIT being used? Is Port B being used?)
From your config:      {0x07,0x0E},                        // (byte 5) TX Con 1:    AES/EBU TX use PortB, WCLK = clk/128 = 192kHz (@24.576MHz), clk = MCLK, valid bit = true 

( Are these two simply backwards? )  

I am getting confused by your register 0x0E settings for both (see below as copied; you have two for the transmitter). I'm going to assume you have register 0x0E set to 0x19 for both, so that your RXCKO output is enabled, and PLL is set to keep running but with output muted on loss of lock.

Transmitter:
{0x0E,0x19}                      // (byte 8) RX Con 2:    RXCKO output disabled, clk divider = 1, auto mute enabled, pll runs free if lose of sync
{0x0E,0x18},                     // (byte 10) RX Con 2:    RXCKO output disabled, clk divider = 1, auto mute enabled, pll runs not free if lose of sync
 
Receiver:
{0x0E,0x19}                          // (byte 8) RX Con 2:    RXCKO output disabled, clk divider = 1, auto mute enabled, pll 

Did you not configure DIR PLL1 in the receiver DIX4192, or can I assume you set to 192 kHz did for both?

Is the OSLIP error happening on both DIX4192 or just your receiver?

----------

For the error status registers: since I'm getting a different read the first time after an "event" (such as removing the cable into the receiver), but a different yet same read thereafter, I assume that these registers simply retain errors, and then refresh upon a read.

For the OSLIP error, with regards to the receiving DIX4192, I am also always getting an OSLIP error. Since the audio seems to be fine, and you're in master mode for Port A, this does not appear to be essential. 

For the Receiver, when you are getting toggling nLOCK pin. I'm using a coax for RX1, and I'm also not using another DIX4192 as transmitter, but a different tool (we don't have 2 DIX4192).  When I unplug the cable, I will lose the lock, though the errors go away after a read.  After I reconnect, I have always gotten working output at Port A, and the errors also go away after a read. 

At any rate, unplugging and replugging repeatedly may be the best intermediate option, if nLOCK does continue to toggle.

Best regards,
Arnold Zhang 

Hi Arnold Zhang,

first of all, thanks for the really great support with that topic!

I am really sorry for some misunderstandings with my last post, I did some copy-paste errors.

• Yes, both devices, transmitter and receiver, are configured to use 192kHz as PLL1 configuration (I simply missed to copy the section to receiver section)
• Yes, your assumption is correct, both are configured to 'mute on Lock loss and leave PLL running' (the option with deactivated LOL was just for test purposes)
• Regarding my configuration/setup: that is a little bit tricky, I have bi-directional connection from transmitter (base) to receiver (extended) device and backward, but my receiver device will use PLL generated clock from DIX (RXCLKO) in device as audio clock and send audio back to transmitter device. One possible configuration is also that I just route back the aes/ebu data through DIX to transmitter.
• Also I did a copy mistake on receiver configuration, as you already mentioned correctly, I am not using PortB on Receiver, I am using Port A to output data. 

Ok, so I will ignore the OSLIP error in that case. As I had never really problems with audio too, I ignored it anyway and just asked to be sure that I didn't miss something.

I am not sure that we talk about the same thing, of course I get a toggling signal (from low to high) on nLOCK pin if I remove cable, but that isn't the problem. With toggling I mean that if I reconnect (and leave reconnected, and therefore having an active aes/ebu stream)  cable, I get sometimes an unstable system which starts to toggle nLOCK signal shortly sometimes. If that happens it looks like as if DIX is not able to resync to aes/ebu stream, even if RXCLKO shows correct clock. As disscussed I can see sometimes in error register that there is a biphase error, which I assume shows that also that DIX is not able to resync PLL correctly on aes/ebu stream.

Best regards,

Max

Hello Max,

I'm not 100% on your set-up. But from your register configuration before, I will assume the following summary view:

0x07 = 0x86,  0x0d = 0x00   -> "Alpha" DIX4192  (Base, Transmitter?)    -> DIT clocked by RXCKO

and

0x07 = 0x06, 0x0d = 0x08   ->  "Beta"  DIX4192   (Extended, Receiver?)  ->  DIT clocked by RXCKI (effectively MCLK)

If I assume "Beta" is the one you're checking nLOCK on, then as I said before, after unhooking the incoming cable, and reconnecting it, the nLOCK stabilizes after a while (some brief flickering for 2 seconds max, at times?), and all register reads of 0x14 give 0x01, or no UNLOCK, Biphase or other errors. This is if I'm only using "Beta", again. 

In the case I assume "Alpha" is the one you're removing the incoming cable from, I also get the same results. 

Essentially I don't seem to be re-creating your error with my abridged set-up. Port A always measures fine. Is there noticeable flickering of the nLOCK light? Mine appears steady. 

Best regards,
Arnold 

Hey Arnold,

wow, it is really awesome how hard you work on this topic, thanks again for that!

Your picture is corret, in our application we have just one cable between base and extended unit (alpha and beta device). Of course we have seperated lines for tx (alpha->beta) and rx (beta->alpha) connection, but they are within one cable, sorry for the missunderstanding. So we loss nLock on both devices shortly, but the nLock toggling will occur only (and just sometimes) on beta device (base backward-receiving) after reconnection (and only if I use LoL option).

Regards,

Max

Hello Max,

Okay, thank you for confirming the picture set-up. (By "separated lines", I assume you mean twisted-pair balanced lines..) 

I'm not sure I'll be able to re-create your set-up, since I only have one DIX4192.  Again, what does the nLock toggling look and sound like..? Can you describe how often it toggles, for example? 

Best regards,
Arnold Zhang 

Hi Arnold,

yes, that was what I meant with "seperated lines" one CAT-5 cable with several twisted-pair balances lines (it has four pairs of and we are using two of them, one alpha>beta and another beta>alpha).

Regarding the toggling, if DIX will fall in this unstable state I can see toggling nLock all 5-10s for two-three times which will result in a short drop-out (because of mute on no lock option).

As I can see this problem only on the base device (beta) which gets aes/ebu data from extended device (alpha), I assume that it has something to do with the fact that I am using recovered clock on alpha device to generate new aes/ebu stream in DIT. Is it possible that this is the cause? Maybe the beta device is not able to resync to this aes/ebu stream (that would be also an explanation for biphase errors). On the other hand, I see stable RXCLKO on beta device all time (even if there are nLock loss events). Also it is not an explanation for me why it is working if I do not use LoL option, as I assume that PLL should always be able to resync to input stream, not only on complete restart.

Best regards,

Max

Hi Arnold,

I do not think that you ask knucklehead questions (funny word, first time I hear it), on the contrary your questions help me a lot re-thinking about some parts of my configuration. However, you are right the set-up sounds a little bit confusing; to be honest our set-up is a little bit untypical for DIX4192, but as we are right now deeply in development I am sorry but I can not describe it more in public forum. Anyhow you helped me a lot! As mentioned in last post I assume that PLL of DIR is not able to resync in all circumstances (or just after some restarts/replug), so it is not recommended for our application to use LoL option. If I will get new information during next steps, I will post it.

Thanks for really great support! Really awesome!

Best regards,

Max

Hello Max,

Thanks for your words, I do hope I have helped out and that the application will work. If does seem that in your setup PLL cannot definitively resync with LoL option, though I would expect it to if you re-plugged a few times... If you do get more info that can be shared, do let us know. 

Best regards,
Arnold Zhang