Trying to sync clocks on two boards, don't know what's wrong

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
Post Reply
Funkster
Junior Member
Posts: 6
Joined: Thu Mar 08, 2012 11:37 am

Trying to sync clocks on two boards, don't know what's wrong

Post by Funkster »

Hi all,

I have two XC-2 ethernet boards and I'm trying to get audio clocks synchronised between the two. I have one set as a talker (using a modified version of the XC-2 ethernet demo that also outputs a local clock on an I2S sync pin so I can scope it), and the other set as a listener. The listener has a PLL (CS2300) grafted to it for clock recovery but the talker does not (I figured since it's a local clock it doesn't need it to produce PTP timestamps - am I right?).

If I set the clock type on the listener to MEDIA_FIFO_DERIVED, the two clocks are pretty similar but not synchronised. Drift is present regardless of whether the ethernet is connected (obviously I have to connect it briefly to get the listener to register its clock).

If set to PTP_DERIVED, the clock on the listener steadily increases or decreases in frequency after application start, until it's a good 10% faster or slower than the talker end, again regardless of ethernet connection.

I definitely have 1722 and PTP messages flying around on the network (seen with wireshark). I'm running in legacy mode as I don't have an AVB switch yet!

Any pointers on what to investigate next would be greatly appreciated.

All the best,
--
Olly


User avatar
Andy
Respected Member
Posts: 279
Joined: Fri Dec 11, 2009 1:34 pm

Post by Andy »

Hi Olly,

I think the first setup you describe is correct. The talker is set to LOCAL_CLOCK and the listener to MEDIA_FIFO_DERIVED.

You mention you don't have a PLL on the talker. How are you generating your audio master clock?
Funkster
Junior Member
Posts: 6
Joined: Thu Mar 08, 2012 11:37 am

Post by Funkster »

Hi Andy,

Thanks for the quick response. In the unmodified XC-2 AVB demo, there is no PLL anywhere and the synth module is used to create audio (so no I2S). I have added an I2S module and a second local clock simply so I can look at the clock on a 'scope - I'm assuming the two local clocks would run at an identical rate due to both being generated from the local oscillators!

In MEDIA_FIFO_DERIVED mode, the drift between the two ends is slow but unacceptable. Monitoring the f_sync lines at both ends (960Hz) I've seen them drift by a millisecond after watching them for half an hour or so.

I have to ask, where would PTP_DERIVED normally be used? I had thought that the whole point of PTP is to sync clocks so it seems a bit odd that I can't used it to do that in this application :o)

Thanks,
--
Olly
User avatar
Andy
Respected Member
Posts: 279
Joined: Fri Dec 11, 2009 1:34 pm

Post by Andy »

The naming of the clock recovery modes is a little confusing. MEDIA_FIFO_DERIVED uses PTP to phase align the clocks, but the frequency is locked to the master clock of the endpoint with LOCAL_CLOCK.

In PTP_DERIVED mode, clock recovery generates a master clock based on 48 kHz 'PTP time'. This clock will not be as stable as the other mode and is susceptible to discontinuities in the PTP clock (as a result of the grandmaster changing). This mode is not normally used.

Can you post the UART debug output from the XC-2 listener board? This will indicate if the media clock has locked or not. It sounds like it hasn't.
Funkster
Junior Member
Posts: 6
Joined: Thu Mar 08, 2012 11:37 am

Post by Funkster »

Found stream 229700.12500000, address 1:50:43:FF:D4:6A, vlan 2
PTP Role: Slave
Media output 0 locked: 17 samples shorter
PTP sync locked
My listener app is a bit of a hybrid, but is mainly based on app_two_channel_listener, ported to the XC-2. It could be that it doesn't have as much debug printf as you would expect.

Thanks!
--
Olly
User avatar
Andy
Respected Member
Posts: 279
Joined: Fri Dec 11, 2009 1:34 pm

Post by Andy »

The debug print indicates that the media clock is locking OK. Are you connecting the two boards through a switch? Have you tried connecting the boards directly via a single Ethernet cable?
Funkster
Junior Member
Posts: 6
Joined: Thu Mar 08, 2012 11:37 am

Post by Funkster »

I was connecting through a switch, but I have just wired the two directly together and restarted the listener app, and the clock drift is present.

Interestingly, this time when I connected the cable (after doing the xrun on the listener and restarting minicom), there is a line missing from the debug data - last time it said "Media output 0 locked: 17 samples shorter " but this time there is no such statement!

I probably wasn't paying enough attention to the 'scope to say that there was definitely drift on the last session (I looked at the debug output and then left it alone) so perhaps this is something to do with my problem.

Cheers,
--
Olly
Funkster
Junior Member
Posts: 6
Joined: Thu Mar 08, 2012 11:37 am

Post by Funkster »

Okay, update... after unplugging and replugging the cable I got a "Media output 0 locked: 18 samples shorter" message and the clocks did stay in sync (drifting back and forth +/- 25us or so but generally staying in the same place). So it seems sometimes the media output does not lock when the cable is connected.

Also, while I was watching it, I just saw: "Media output 0 lost lock Media output 0 locked: 1 samples shorter" and the listener clock jumped a long way. I didn't touch the cable, it did this all by itself which is a bit worrying!

Cheers,
--
Olly
User avatar
Andy
Respected Member
Posts: 279
Joined: Fri Dec 11, 2009 1:34 pm

Post by Andy »

I suspect the problem is jitter caused by generating your audio master clock from the 100 MHz reference clock in the talker. Can you hook up another PLL to the talker and try the proper I2S interface?
Funkster
Junior Member
Posts: 6
Joined: Thu Mar 08, 2012 11:37 am

Post by Funkster »

Sorry for the delay - ripped a leg off the first CS2300 while soldering the last wire!

Now done, and it does seem to have stopped it losing lock. Word clocks stay reasonably well synced, they're drifting around a quarter of a sample or so but I'm sure that that's down to my PLLs being mounted on mod wire with inadequate decoupling.

Thanks for the help!
--
Olly
Post Reply