Detecting phase changes with an MCU

Go To Last Post
30 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Apologies if this isn't the right place to post this, but I haven't selected an MCU yet and the selection will depend on how I'm going to solve this issue.

 

I have a 200kHz carrier that has a low frequency (25 bits/second) data channel that is indicated by the phase of the carrier advancing or retarding by 22.5°. The data channel uses Manchester coding so the frequency always averages out to 200kHz over one second (with dummy bits inserted as required). Basically it stretches or shortens one cycle of the carrier to indicate high or low bits, and you recover the clock in the usual way with Manchester coding.

 

The carrier is a square wave derived from a sine wave, but can have some noise at times. I need to be able to detect the phase changes on the cycle they happen, because some of the bits start at precise times that I need to synchronize to.

 

I can demodulate the data by XOR mixing the carrier with a 200kHz square wave that I steer to be 180 degrees out of phase with the carrier, so they mostly cancel each other out except for the low frequency data stream that I separate with a low pass filter. Of course the problem with this is that the output of the filter is delayed and the delay is basically random, depending on the tolerances of the analogue components and the temperature.

 

The steering is done by low pass filtering the XOR output, when the two signals are in phase they cancel out and produce close to VCC. I have another square wave that is 90 degrees out of phase with the first one, and with low pass filtering gives me the sign of the error so I know if I need to advance or retard. I sample these voltages with an ADC.

 

So the issue is how do I detect the phase changes on the cycle that they happen, or at least at some fixed time after they happen that isn't subject to variances due to analogue circuits. I need to measure down to 1uS, ideally lower.

 

Are there any MCUs that have timers that can do "window capture"? By that I mean detect a transition within a certain timeframe, and ignore ones outside it. Then I could have two windows for the advance/retard transitions, but I don't know of any MCUs that can do that. STM32 have a gate function that allows one timer to control when another time runs, so potentially I could have a chain of timers maybe.

 

The obvious solution is to just have the timer capture every cycle and an interrupt check the captured value, but the problem with that is it will trigger 200,000 interrupts a second. I could do it but would need to dedicate an MCU to it. An AVR Dx at 20MHz would only have 100 cycles to handle the interrupt or loop, but I suppose that's within the realms of possibility.

 

Any other clever ideas?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This might be worth taking a look, though not sure if AVR's offer NCO.

 

http://ww1.microchip.com/downloa...

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps take a look of a FM sound decoder.

One problem for you is that you don't have a sine wave. You will be sensitive to the logic trigger level it will give the signal a DC level (2.harmonic noise).

So perhaps only look at high going edge, at this low speed all can be done with counters.

But main thing make a PLL that run at carrier (slow changes so you can't see data). And then compare it with the incoming signal.   

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I do have a sine wave, and that's basically what I have done. The MCU is acting as a PLL that is slow enough for the data to be separated by the low pass filter.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

This might be a good use for the Configurable Custom Logic (CCL) block in the Mega0/1 devices. 200KHz is getting pretty fast for a device that is clocked at a few MegaHertz; f_cpu = 10MHz only gives you 50 clock cycles per signal cycle.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

This might be a good use for the Configurable Custom Logic (CCL) block in the Mega0/1 devices. 200KHz is getting pretty fast for a device that is clocked at a few MegaHertz; f_cpu = 10MHz only gives you 50 clock cycles per signal cycle.

 

Jim

 

Thanks. How would the CCL help in this case? I'm not sure I can see how you could use it to window the timers, or did you have something else in mind?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

22.5 deg at 200KHz should give 5 clk on a 16MHz cpu, so 10 clk diff for 0 and 1  for 1000 (500 or 2000 depending of modulation). So it should not be to bad.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been able to start and stop one timer with another using CCL. Since it does logical operations in hardware, its much faster than executing code and avoids the time overhead of high-rate operations. That was all I was thinking. Maybe that won't be useful to you?

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since the baud rate is so low, (many hole periods for each bit about 1000 depending of modulations form), then perhaps clk a timer with the 200KHz and then a interrupt for something like each 200 clk , and then use the time difference between each interrupt.

 

if you fall into a shift there should be 10 clk (@16MHz) difference. And some with about 0 and then one with 10 clk the other way. (if you don't keep track of where the shift could be you will need look over two bloks)

 

normally:

0 0 10 0 0 0 0 -10 0 0 0 0 0 0 0 0 0 0 10 .......

but it could be

0 0 6 4 0 0 0  -5 -5 0 0 0 0 .........   

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mojo-chan wrote:

Apologies if this isn't the right place to post this, but I haven't selected an MCU yet and the selection will depend on how I'm going to solve this issue.

 

I have a 200kHz carrier that has a low frequency (25 bits/second) data channel that is indicated by the phase of the carrier advancing or retarding by 22.5°. The data channel uses Manchester coding so the frequency always averages out to 200kHz over one second (with dummy bits inserted as required). Basically it stretches or shortens one cycle of the carrier to indicate high or low bits, and you recover the clock in the usual way with Manchester coding.

 

The carrier is a square wave derived from a sine wave, but can have some noise at times. I need to be able to detect the phase changes on the cycle they happen, because some of the bits start at precise times that I need to synchronize to.

So the issue is how do I detect the phase changes on the cycle that they happen, or at least at some fixed time after they happen that isn't subject to variances due to analogue circuits. I need to measure down to 1uS, ideally lower.

That's sounding quite tough.  How much noise and jitter is on the 200kHz ? What is the drift and stability ?

 

The 25Hz data rate is quite low, which suggests there is quite a lot of noise in this system ?

You are hoping to capture a step of 312.5ns which comes along every 40ms  - 5 counts at 16Mhz or 15+ counts at 50MHz

To do that, you have to hope the noise is well below 312.5ns - is that true ?

 

Do you mean you want to have absolute time lock to better than 1us ?  Do you even know which edge steps ? With a 200kHz source, edges arrive every 2.5us

That does not allow for much averaging or latency.

 

Simplest capture design : 

because the date rate is so low, you could divide the 200kHz, - eg an SOT25 external part like 74AHC1G4208 could take your sine wave and divide by 256 to give 781.25Hz, but you now need to look for a 312.5ns step in that output, one part in 4096, and you only know it happened inside a 1.28ms window. That's likely to not meet your 'sync to edge' needs.  ie   Division lowers the interrupt rate, but imposes drift and jitter rules that are likely outside RC oscillators.

 

More complex design : 

A tracking oscillator is possible, but would work better at a faster timer clock. 16MHz is only /80 to 200KHz so you would be /80/81/79 in a mixed basis, with +/- 1 jitter on your sync-clock 

A crystal (N x 200k) would help reduce the correction jitter, and means you have more option to slow down the tracking slew rate. 

 

You are right an XOR would give a repeating error signal, that would decay at your lock speed. That can be a SW XOR or a HW XOR. 

 

 

CLK Speed is important, so let's try 24MHz of AVR DA/DB etc series.  that's /120/121/119  to lock, and  step is 7.5 sysclks 

If you check and DPLL lock-react on every _/= edge, the tracking time is 7 samples, and your impulse error would be 0,0,0,0,0,0,7,6,5,4,3,2,1,0,1,0,1,-1,0 etc 

If you lock-react every 3 _/= edges with a Xtal, your impulse error (one way) would be (ideally) 0,0,0,0,0,7,8,7,6,7,6,5,6,5,4,5,4,3,4,3,2,3,2,1,2,1,0,0,0,0,0.....1..0,0,0,0,0..... -1,0,0,0,0,0,0   etc

 

Software can look for that triangular phase impulse and apply enough noise filtering to be reliable.

The system noise is really going to set your edge-time-precision achieved.

 

An analog VCXO is another way to lock, which would reduce the digital noise of the DPLL, but I think the system jitter is going to be the limit here.

If you really need best time-lock to an edge step, it's hard to see anything other than an ASM coded dedicated MCU.  

 

The highest-MHz cheapest small MCU that digikey lists is the 50MHz EFM8BB51  ~40c/1k, tho that needs an external clock oscillator, no XTAL support. Maybe RC OSC trim is 'good enough' here ?

Say a 0.1% trim step, gives 5ns walk per 5us edge, which is about 62 edges to walk your 312ns, a correction every 4 edges limits that to 20ns, but you have imposed a low ceiling on your correction rate. 

At 50MHz you have a code budget of 250 sysclks - not a whole lot :) 

 

 

Last Edited: Tue. Nov 23, 2021 - 12:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

Since the baud rate is so low, (many hole periods for each bit about 1000 depending of modulations form), then perhaps clk a timer with the 200KHz and then a interrupt for something like each 200 clk , and then use the time difference between each interrupt.

Yes, that would work, but needs a crystal at each end so jitter does not swamp the small step looked for, and you also limit the time-precision to 'somewhere inside the interrupt'. ~1ms at 200 clk checks. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
Since it does logical operations in hardware,
likewise by GreenPAK though greatly more logic elements than CCL (LUT : GreenPAK <= 26, AVR Dx CCL = 3)

https://www.dialog-semiconductor.com/greenpak-application-notes?title=&combine=decod&family=All

[bottom]

AN-1042 RC IR decoder

GreenPAK | Dialog

 

edit : XCL is greater in features than CCL.

AT01084: XMEGA E Using the XCL Module | Application Note | Microchip Technology

E5's XCL doing 2Mbps(!!!) FSK, appnote to follow | AVR Freaks

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Tue. Nov 23, 2021 - 12:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
though not sure if AVR's offer NCO.
No on AVR VCO

AVR® Microcontrollers Peripheral Integration

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mojo-chan wrote:

The obvious solution is to just have the timer capture every cycle and an interrupt check the captured value, but the problem with that is it will trigger 200,000 interrupts a second. I could do it but would need to dedicate an MCU to it. An AVR Dx at 20MHz would only have 100 cycles to handle the interrupt or loop, but I suppose that's within the realms of possibility.

Any other clever ideas?

 

Another approach entirely, is to focus on your phase comparator, and use a HC4046/7046/9046/LV4046 type phase lock loop.

That is set up to lock to 200KHz with high gain, and the analog control voltage will have an impulse step on every modulation edge.

the phase of the carrier advancing or retarding by 22.5° will give a easy to see analog pulse, or because this is mostly locked (impulse every 40ms), you could use the digital PCP_OUT via a filter to interrupt the MCU

Getting the phase would be possible with a quick sample of PC2 out, tho that is tri-state pin, or maybe the PC3 on the LV4046 can demodulate directly ?

 

With such an external part the MCU loading drops significantly.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

I've been able to start and stop one timer with another using CCL. Since it does logical operations in hardware, its much faster than executing code and avoids the time overhead of high-rate operations. That was all I was thinking. Maybe that won't be useful to you?

 

Jim

 

Hmm, that seems worth investigating. What I really need is something that examines the width of each cycle. Maybe it's possible with CCL and a chain of timers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:

mojo-chan wrote:

Apologies if this isn't the right place to post this, but I haven't selected an MCU yet and the selection will depend on how I'm going to solve this issue.

 

I have a 200kHz carrier that has a low frequency (25 bits/second) data channel that is indicated by the phase of the carrier advancing or retarding by 22.5°. The data channel uses Manchester coding so the frequency always averages out to 200kHz over one second (with dummy bits inserted as required). Basically it stretches or shortens one cycle of the carrier to indicate high or low bits, and you recover the clock in the usual way with Manchester coding.

 

The carrier is a square wave derived from a sine wave, but can have some noise at times. I need to be able to detect the phase changes on the cycle they happen, because some of the bits start at precise times that I need to synchronize to.

So the issue is how do I detect the phase changes on the cycle that they happen, or at least at some fixed time after they happen that isn't subject to variances due to analogue circuits. I need to measure down to 1uS, ideally lower.

That's sounding quite tough.  How much noise and jitter is on the 200kHz ? What is the drift and stability ?

 

The 25Hz data rate is quite low, which suggests there is quite a lot of noise in this system ?

You are hoping to capture a step of 312.5ns which comes along every 40ms  - 5 counts at 16Mhz or 15+ counts at 50MHz

To do that, you have to hope the noise is well below 312.5ns - is that true ?

 

Do you mean you want to have absolute time lock to better than 1us ?  Do you even know which edge steps ? With a 200kHz source, edges arrive every 2.5us

That does not allow for much averaging or latency.

 

Simplest capture design : 

because the date rate is so low, you could divide the 200kHz, - eg an SOT25 external part like 74AHC1G4208 could take your sine wave and divide by 256 to give 781.25Hz, but you now need to look for a 312.5ns step in that output, one part in 4096, and you only know it happened inside a 1.28ms window. That's likely to not meet your 'sync to edge' needs.  ie   Division lowers the interrupt rate, but imposes drift and jitter rules that are likely outside RC oscillators.

 

More complex design : 

A tracking oscillator is possible, but would work better at a faster timer clock. 16MHz is only /80 to 200KHz so you would be /80/81/79 in a mixed basis, with +/- 1 jitter on your sync-clock 

A crystal (N x 200k) would help reduce the correction jitter, and means you have more option to slow down the tracking slew rate. 

 

You are right an XOR would give a repeating error signal, that would decay at your lock speed. That can be a SW XOR or a HW XOR. 

 

 

CLK Speed is important, so let's try 24MHz of AVR DA/DB etc series.  that's /120/121/119  to lock, and  step is 7.5 sysclks 

If you check and DPLL lock-react on every _/= edge, the tracking time is 7 samples, and your impulse error would be 0,0,0,0,0,0,7,6,5,4,3,2,1,0,1,0,1,-1,0 etc 

If you lock-react every 3 _/= edges with a Xtal, your impulse error (one way) would be (ideally) 0,0,0,0,0,7,8,7,6,7,6,5,6,5,4,5,4,3,4,3,2,3,2,1,2,1,0,0,0,0,0.....1..0,0,0,0,0..... -1,0,0,0,0,0,0   etc

 

Software can look for that triangular phase impulse and apply enough noise filtering to be reliable.

The system noise is really going to set your edge-time-precision achieved.

 

An analog VCXO is another way to lock, which would reduce the digital noise of the DPLL, but I think the system jitter is going to be the limit here.

If you really need best time-lock to an edge step, it's hard to see anything other than an ASM coded dedicated MCU.  

 

The highest-MHz cheapest small MCU that digikey lists is the 50MHz EFM8BB51  ~40c/1k, tho that needs an external clock oscillator, no XTAL support. Maybe RC OSC trim is 'good enough' here ?

Say a 0.1% trim step, gives 5ns walk per 5us edge, which is about 62 edges to walk your 312ns, a correction every 4 edges limits that to 20ns, but you have imposed a low ceiling on your correction rate. 

At 50MHz you have a code budget of 250 sysclks - not a whole lot :) 

 

 

 

In answer to your questions...

 

This is a radio system so noise varies with conditions, sometimes it's very clean and other time's it's quite noisy. Jitter is in the order of ±200ns when reception is good. I might be able to improve that a bit. I know this makes it a borderline, so I'm wondering if this is even possible to do. The good news is that I don't need to synchronize with every bit, just enough of them that I can recover the clock and steer another oscillator to reproduce it.

 

Stability is however excellent, an atomic clock is used to discipline the 200kHz.

 

The low data rate is because the system is ancient and because some applications use the 200kHz as a timing reference, so by having the data rate very low it doesn't cause issues for slow analogue PLLs.

 

The phase change is always on a rising edge, between that edge and the falling edge.

 

At the moment I'm using an STM32 dev board running at 150MHz (750x200kHz) and am open to using either one of those or a SAM if very high clock speeds are needed. Thing is that's still only 750 clock cycles on the MCU per cycle of 200kHz, so a very high interrupt rate. I was hoping I could maybe use a smaller MCU dedicated to just detecting phase changes, and a "main" MCU for decoding the data and communicating with the outside world. But as you say, a 24MHz DA/DB is only going to have 120 clock cycles to handle this. It should be fine, use a timer with capture to make the measurement, sleep and interrupt for timing stability... There will be a relationship to the analogue low pass filtered data stream too, offset by around 35-40ms, which gives a bit of a window for initial noise filtering.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:

mojo-chan wrote:

The obvious solution is to just have the timer capture every cycle and an interrupt check the captured value, but the problem with that is it will trigger 200,000 interrupts a second. I could do it but would need to dedicate an MCU to it. An AVR Dx at 20MHz would only have 100 cycles to handle the interrupt or loop, but I suppose that's within the realms of possibility.

Any other clever ideas?

 

Another approach entirely, is to focus on your phase comparator, and use a HC4046/7046/9046/LV4046 type phase lock loop.

That is set up to lock to 200KHz with high gain, and the analog control voltage will have an impulse step on every modulation edge.

the phase of the carrier advancing or retarding by 22.5° will give a easy to see analog pulse, or because this is mostly locked (impulse every 40ms), you could use the digital PCP_OUT via a filter to interrupt the MCU

Getting the phase would be possible with a quick sample of PC2 out, tho that is tri-state pin, or maybe the PC3 on the LV4046 can demodulate directly ?

 

With such an external part the MCU loading drops significantly.

 

That's an interesting idea. With a bit of effort a comparator could probably pull that step out and convert it to a pulse.

 

This also reminded me of a design for demodulating that I saw which used an FM demodulator chip, I think from Motorola. I will go dig into my notes and look for that again. IIRC there was some hackery to make it make it work at 200kHz rather than the designed ~100MHz carrier for FM broadcasts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is both transmitter and receiver clk very accurate?

And why do you need to know exactly when the shift happen? (does something need to be in sync?)

if you only need to decode the data (that is slow) then it doesn't matter if it's delayed 1/10 of a bit (or does it).

 

I would say that a tiny 85 running with a internal clk will spend less that 10% of the time decoding the signal. 

 

Perhaps look of how DGPS works that is about the same freq and data speed.

 

An other way would be to use the ADC and under sample, if you sample with lets say 12.5KHz and have your 200KHz PLL control the time so the sample is close to the zero crossing (high delta V), it will give close to same value all the time (because that is actually what control the PLL), but there should be two values depending of the phase.     

 

A book like Digital Signal Processing in Communication Systems is good to get ideas.

 

 

Add: 

In this case the 200KHz PLL also only need to be 12.5KHz

 

Add:

Remember that there are more information in a 12.5KHz sinewave than in a 200KHz binary signal.

Last Edited: Tue. Nov 23, 2021 - 10:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

Is both transmitter and receiver clk very accurate?

And why do you need to know exactly when the shift happen? (does something need to be in sync?)

if you only need to decode the data (that is slow) then it doesn't matter if it's delayed 1/10 of a bit (or does it).

 

I would say that a tiny 85 running with a internal clk will spend less that 10% of the time decoding the signal. 

 

Perhaps look of how DGPS works that is about the same freq and data speed.

 

An other way would be to use the ADC and under sample, if you sample with lets say 12.5KHz and have your 200KHz PLL control the time so the sample is close to the zero crossing (high delta V), it will give close to same value all the time (because that is actually what control the PLL), but there should be two values depending of the phase.     

 

A book like Digital Signal Processing in Communication Systems is good to get ideas.

 

 

Add: 

In this case the 200KHz PLL also only need to be 12.5KHz

 

The transmitter clock is very accurate, synchronized with atomic clocks and probably GNSS for TOD. The receiver has to use the 200kHz carrier as a reference to steer its own clock.

 

I need to generate a PPS pulse which is synchronized to one bit. I can have a free-running local oscillator for a few seconds between synchronizations if there is temporary noise. Decoding the data is secondary and it doesn't matter if that gets delayed, hence the use of a low pass filter to demodulate it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So what is max legal jitter on the 1PPS ? (we know that there are no long term error).

 

Does this mean that the transmitter always send data? 

or stay at one angle most of the time and first shift is the point where all get's in sync?

 

Can you tell what it is ? (perhaps give a link)

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

So what is max legal jitter on the 1PPS ? (we know that there are no long term error).

 

Does this mean that the transmitter always send data? 

or stay at one angle most of the time and first shift is the point where all get's in sync?

 

Can you tell what it is ? (perhaps give a link)

 

 

 

Sorry I can't be too specific about the project yet. The transmitter is on 24/365. Ideally 1uS jitter on the PPS.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But does it send data all the time?

or start sending each sec?

It sounds like it has about the same function as a radio controlled clock, to put everything in sync.

 

I will say that 1uS is a small value when your base clk is 200KHz (5us), if you only look on on off signals, perhaps have a 200KHz timer interrupt that "fire" something like 45 deg before the shift (with manchester coding there for sure is a shift at center of the bit), and then make 1-2 MHz ADC samples the next 90 deg. so you can see exactly when the shift was (remember that the HW filters give a delay), and use that 0.9999.. sec later (basically update the 200000 Hz timer)   

Last Edited: Tue. Nov 23, 2021 - 02:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

But does it send data all the time?

or start sending each sec?

It sounds like it has about the same function as a radio controlled clock, to put everything in sync.

 

I will say that 1uS is a small value when your base clk is 200KHz (5us), if you only look on on off signals, perhaps have a 200KHz timer interrupt that "fire" something like 45 deg before the shift (with manchester coding there for sure is a shift at center of the bit), and then make 1-2 MHz ADC samples the next 90 deg. so you can see exactly when the shift was (remember that the HW filters give a delay), and use that 0.9999.. sec later (basically update the 200000 Hz timer)   

 

It's a continuous stream of bits at 40ms intervals, all the time. If there is no meaningful data to send it sends filler.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One possible use is CCL as phase detector. XOR (one of the CCL logic gate options) will function as a phase detector. Presence of flip-flops may also help.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

How about a DPLL to extract the "long-term" timing synch....didn't see much using an AVR alone, but how about adding this DPLL chip

 

https://www.ti.com/lit/ds/symlin...

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

if it is measuring a pulse length- then ATTiny13A + 20Mhz external osc, INT0 and PCINT0 can do it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mojo-chan wrote:

 

In answer to your questions...

 

This is a radio system so noise varies with conditions, sometimes it's very clean and other time's it's quite noisy. Jitter is in the order of ±200ns when reception is good. I might be able to improve that a bit. I know this makes it a borderline, so I'm wondering if this is even possible to do.

Does that  'carrier advancing or retarding by 22.5° ' mean it changes by 22.5°, or that it swings 45° from -22.5° to +22.5°

 

mojo-chan wrote:

The good news is that I don't need to synchronize with every bit, just enough of them that I can recover the clock and steer another oscillator to reproduce it.

Stability is however excellent, an atomic clock is used to discipline the 200kHz.

That makes it more possible, but the high jitter level increases the number of cycles needed to make a decision, so wobbles your absolute time 

Does your local system also have high precision clock sources ? (which you want to lock to this ?)

 

mojo-chan wrote:

 

 I was hoping I could maybe use a smaller MCU dedicated to just detecting phase changes, and a "main" MCU for decoding the data and communicating with the outside world. But as you say, a 24MHz DA/DB is only going to have 120 clock cycles to handle this. It should be fine, use a timer with capture to make the measurement, sleep and interrupt for timing stability... There will be a relationship to the analogue low pass filtered data stream too, offset by around 35-40ms, which gives a bit of a window for initial noise filtering.

A small MCU has appeal, as those bigger ones are like oil tankers :)

 

mojo-chan wrote:

Who-me wrote:

Another approach entirely, is to focus on your phase comparator, and use a HC4046/7046/9046/LV4046 type phase lock loop.

That's an interesting idea. With a bit of effort a comparator could probably pull that step out and convert it to a pulse.

I think it's well worth setting up a couple of 4046 variants on the bench as they have various phase comparators and can show jitter and lock steps in an analog manner.

You can then see if you can get a MCU alone 'nearly as good' or decide to keep the 4046 :)

I have used 4046 with Ceramic resonators to give high-Q PLLs, when you know 'where things will be'. Use a small varicap.

 

Addit : What is the needed capture time here ? ie does this modulation or carrier come and go ?

 

 

 

Last Edited: Tue. Nov 23, 2021 - 08:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is a TI  app note describing some phase detecting implementations

https://www.ti.com/lit/an/sdla00...

 

an interesting write-up

https://www.edn.com/two-gates-an...

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 mojo-chan wrote:

Stability is however excellent, an atomic clock is used to discipline the 200kHz.

That's good, so I think a TCXO or a VCTCXO would help as then your phase-walking is very slow, and you have choices about how often to sample/average to reduce the noise & jitter.

19.2MHz and 20.0MHz are common and  26MHz is also common, but current AVRxxDD prelim data gives no margin to 24MHz, even tho it specs a 24MHz HFOSC  - shame the specs exclude 26MHz TCXOs, as that's one of the highest volume oscillators.  

 

 

mojo-chan wrote:

The good news is that I don't need to synchronize with every bit, just enough of them that I can recover the clock and steer another oscillator to reproduce it.

If you want to recreate the atomic clock, you will need a VCTXO and some care to manage the very slow modulation as most lock schemes will try to follow that.

Perfect lock here would need a scheme that looks for and accepts two 'phase baskets' for lock, so does not try to follow the modulation.

 

A VCTCXO and a AVR64DD14 would be a nice pairing here, but that's not an available part yet :)

 

- so maybe an AVR32DA32T-E/PT or similar MCU  something with Xtal OSC and DAC and timers and CLU

DAC drives the VCTCXO and the timers sample at some lower rate to make lock decisions. The two phase lock sw, will know which phase it is currently tracking, so can decode data 

 

Addit: What is the bandwidth of the modulation data and transmission & Receive  path ? 

The phase steps may not be instant, eg a 10kHz BW could mean the phase step takes maybe 20 carrier cycles to fully apply.

 

Last Edited: Wed. Nov 24, 2021 - 11:13 PM