Anyone know about the CTMU on dsPICs for time measurement?

[Illusionist]

As part of my GPSDO project, I'm trying to use the CTMU on a dsPIC 33EP128MC202 to measure the time between two pulses. I would like to be able to measure them to about 1ns resolution, all the way down to zero (in-phase).

Sounds simple... the datasheets claim <1ns resolution and the operating principle is trivial. I cannot get consistent readings though.

For testing, I have now set up a pulse generator and delay line, so have a stable and accurate pulse separation of 0ns to 255ns in 1ns steps. My oscilloscope confirms this and the pulses are nice and sharp, nothing there that should cause any issue with the PIC.

The PIC, however, gives readings all over the place and cannot get anywhere near zero. For instance, if I set a 100ns delay, the ADC will read anywhere from 400 to 500, changing constantly, and if I drop to 1ns the PIC does not read below about 200. At zero it will read around 200 or full scale (pulses in wrong direction by a fraction). It's as if there is a huge offset, in addition to just being highly erratic. It behaved just the same when using the PPS signals. (And yes, I am discharging the sample capacitor.)

Certainly, the readings are nothing like the supposed t=V*C/I

I can post all the code and circuit (it's simple enough though) or I have it posted over at Microchip's forum, where no-one has been able to help: https://www.microchip.com/forums/m1105541.aspx

Any help please... before I give up on the CTMU as a bad job?

[David Hess]

The CTMU can do it but it requires offset and gain calibration and I am not sure how noisy it will be.  If you want 1 nanosecond accuracy, then aim for at least 100 picosecond resolution.

The analog side of getting the low jitter signals into the CTMU with low jitter is not trivial.

[Illusionist]

I wasn't overly bothered about calibration at first, because really all I needed was a relative measure which I could use to bring the pulses together. All I needed was it to measure close to zero (like the advertised <1ns), instead it seems to be unable to read below 20-ish ns. There shouldn't be any appreciable offset (the docs don't mention any), certainly not the 1/5 of full scale that I'm seeing as the minimum reading.

The signals on the 'scope that the PIC is getting, measured right at its pins, are very stable with fast rise time. The time difference shows no instability at 10ns/division.

I rigged up the delay line to try and characterize the thing. The numbers are so all over the place, with a seemingly near enough perfect input, that it seems pointless to even try.

I really can't figure out what is going wrong... I can't believe the CTMU is this rubbish but I'm at a loss now. I've even tried replacing the dsPIC in case I had a faulty one. There must be something I'm doing wrong, but it's hardly complicated and I've tried every variation on the code that I can think of.

[PCB.Wiz]

Certainly, the readings are nothing like the supposed t=V*C/I

I can post all the code and circuit (it's simple enough though) or I have it posted over at Microchip's forum, where no-one has been able to help:

What does the waveform look like on the sampling Cap ?
You will likely find that any inputs are SysClk sampled, which may be why you cannot resolve  to ns levels.
You may need external HW to control the sample/hold, outside of SysCLK.
 

[Illusionist]

The sampling capacitor is the ADC sample capacitor, internal to the PIC - I can't directly access it. The CTMU current switch is asynchronous to the clock and the datasheet specifically claims sub-ns resolution.

I'm going to try adding an external capacitor and playing around like that, although it absolutely should not be necessary (and  counterproductive for the ns range I'm measuring) according to the documentation.

I'm running out of ideas though.

[MosherIV]

What is the clock source for the dsPIC?
Does the dsPIC use PLL to internally increase the freq of the clock source?
Is the CTMU peripheral also using the main clock as the clocking of the timer?

What you are trying to do is to use a lower stability clock source to measure the stability of a higher stability clock source.
When you do get the CTMU to work, you will find that it will give random results.
The clock source of the dsPIC (xtal) is less stable then what you are trying to measure (ocxo or 10KHz from gps).

[Illusionist]

The dsPIC uses the disciplined OCXO as it's clock. Besides, the CTMU doesn't use the clock for measuring. It's asynchronous logic.

Anyway, I've made some progress. The extreme jumping around was caused by a dirty socket pin where the dsPIC was inserted. The dsPIC is now seeing what my oscilloscope is (I was clipped on the socket pin, not the PIC pin) and I have readings that vary by only a few counts for a fixed delay. That might well be measuring a touch of actual jitter since the resolution is around 0.3ns (very roughly).

I've found the speed limit as the phase delay approaches zero: between 3ns and 4ns. It seems the logic just can't switch the current source off more quickly than that after switching it on. At 3ns difference, the CTMU always misses the second pulse edge and the ADC goes full scale. At 4ns, it always catches the edge and I get the minimum, offset reading.

However, that large offset (1/5 full scale) remains. I've not got to the bottom of that yet. Even if my analog ground was messed up (that's my next thing to chase) I can't see how it could cause an offset since the SAR is measuring relative to it. The 4ns limit above goes nowhere near accounting for this amount of offset compared to the slope of the readings.

The investigation continues...

[PCB.Wiz]

I've found the speed limit as the phase delay approaches zero: between 3ns and 4ns. It seems the logic just can't switch the current source off more quickly than that after switching it on. At 3ns difference, the CTMU always misses the second pulse edge and the ADC goes full scale. At 4ns, it always catches the edge and I get the minimum, offset reading.

That makes sense, as the logic needs some minimum time to also define the states.

However, that large offset (1/5 full scale) remains. I've not got to the bottom of that yet. Even if my analog ground was messed up (that's my next thing to chase) I can't see how it could cause an offset since the SAR is measuring relative to it.

That could be simple charge injection effect ?
For the primary use of capsense, they only care about changes, so offsets are not going to bother them.

With the above min skew effect, that makes zero-ing this out not so simple... but maybe you can calibrate with two test delays, one sysclk separated, to derive the zero point, and the ns/mV ?

[David Hess]

I wasn't overly bothered about calibration at first, because really all I needed was a relative measure which I could use to bring the pulses together. All I needed was it to measure close to zero (like the advertised <1ns), instead it seems to be unable to read below 20-ish ns. There shouldn't be any appreciable offset (the docs don't mention any), certainly not the 1/5 of full scale that I'm seeing as the minimum reading.

With low values of integration capacitance, offset from charge pumping through the transistor switches becomes significant.  Only slightly more advanced designs get reliable 40 picosecond resolution or better with low noise but the switching circuits have all kinds of subtle design issues.

Typically some sort of self calibration mode is included in the design where the digital inputs are supplied with different timing references to calibrate offset and gain.  Two asynchronous signals might be applied to generate a histogram for linearity correction.