Potential over-driving of the 40 MHz oscillator

[dancollins]

This is an awesome design and, as part of the team in NZ keen on getting a few made at JLCPCB, I started reviewing the design. At this stage, just the layout and BOM. I noticed X1 is a 40 MHz oscillator being used to drive both the LDC1612 and LDC1614 devices and, for at least the JLCPCB BOM, is a YXC part: https://www.lcsc.com/product-detail/Oscillators_YXC-O705040MEDA4SC_C24796.html

Reading the datasheet, I note the oscillator output is rated to 15 pF - which isn't that much! Especially when driving the signal across the PCB as it is now.

Can I recommend updating the design? One option would be using a clock buffer to up the drive strength and adding series termination to cut down on reflections (40 MHz is pretty quick, and you're competing with just using the internal oscillators of the LDC161x parts). Another option could be using the microcontroller instead - the internal PLL could be tuned to (maybe not exactly) 40 MHz and used to drive the two inductive sensors. The upshot here is fewer clock sources (multiple oscillators can cause EMI problems, which you'd be really unlikely to see issues from on a small project), and you would also be free to use an STM32F103 part (just because they're really cheap and easy to get).

Keen to hear your thoughts around this, and whether you have tried probing the clock output with a scope? Note that scope probes are typically around 2 pF or so. If you're already right on the limit of that clock buffer then perhaps the scope would tip it over the edge.

[spoter368]

Hi Dan!

Thanks for your in depth analysis of my design! Sounds like you've put more thought into it than I did, as I just used the first 40MHz oscillator with a decent PPM rating I could find on LCSC. I personally have not taken a scope reading of the CLK line, nor do I have the equipment necessary to perform such a measurement; however perhaps I could use a scope at work to do that on my own spare time. On the other hand though, I have already had the devices built with the oscillator I specified in the BOM and have confirmed they do work. I can't say for certain if I mass produced these that 100% of them would work, because as you said, they might be right on the edge of not working, but feel free to do any additional analysis you deem necessary and post the results here. I'd be happy to consider other options from LCSC.

As I mentioned in issue #1 , I deliberately made the decision to use the STM32F042 over something cheaper and more available like the STM32F103 to simplify my design. Originally, I tried to get away with not using the 40MHz clock either, and just use the internal clock of the LDCs, but I found their noise level to be too high to have the mouse distinguish when a user is or is not using it (how it knows when to hone the axes to zero, see firmware for details). If people really believe the F103 is the way to go though, I might be open to redesigning it sometime in the future.

[dancollins]

FWIW, this is a low-volume product and whether you use an F042 or F103 is neither here nor there. If it were me, I'd be on an nRF52840. I have much more experience on the ST parts (probably the last 15 years of my career is mostly ST), but the nRF part includes Bluetooth for a wireless option ;)

WRT the clocks - I figured there was a good reason you had an external clock. Did you consider crystals over an oscillator? No real reason there - and it's a little sad the LDC's don't have a clock-out option. I believe the F042 will have the same clocking options as the F103 (and every other ST-series part I've used!) so you could still explore that.

@Llybel is working on a fork with the F103, and doing the clock distribution I'd recommended. Basically just star-routing and series termination assuming about 50 ohms. We can adjust if needed, and I'll be collecting some scope traces as part of that. I reckon you're right that what you have will probably work totally fine - it's just the sort of comment I can't keep to myself when reviewing a design!

Really love your work, mate! You've inspired a group of us to do a fork - and I'll still be tempted to fork to the nRF52 ;)

[dancollins]

I'll include our findings here. Naturally it wont include what you have now, but we'll be able to see how well our fork does (or doesn't!) work :)

[lpurdy01]

I have one of the last revision with the old oscillator, and a 100Mhz oscope, so I wanted to provide some data to this conversation.
At OSC

At LDC1612

At LDC1614

At_LDC1612.csv
At_LDC1612_csv.txt
At_LDC1612_png.txt
At_LDC1614.csv
At_LDC1614.txt
At_LDC1614_png.txt
At_OSC.csv
At_OSC_csv.txt
At_OSC_png.txt

These were captured with AC coupling 1.0 GS/s. (I don't have any of those nifty spring probes around to do a DC capture, and the ground lead would cause far too many problems.)

From the OSC to the LDC1614 (across the board) it does look like the [rise_time, fall_time] increases from [1.3ns,1.9ns] to [2.7ns,3.6ns]. The datasheet for the ASV-40.000MHZ-EC-T says a typical Tr or Tf is 2.4ns to a max of 4.0ns.

The ASV-40.000MHZ-EC-T has the same output load rating as the new O705040MEDA4SC. 15pF

I would suspect it manages this only because it looks like @spoter368 put a lot of effort into minimizing the coverage of the ground planes, so there isn't much capacitance in the board.

@dancollins, @Llybel, Could you take a look at these graphs and see if you can glean more out of them?

[Tropaion]

Really love your work, mate! You've inspired a group of us to do a fork - and I'll still be tempted to fork to the nRF52 ;)

I can't say much about the oscillation topic since I'm working more in the digital area, but an version with bluetooth, either nRF52 or preffered ESP32 would be really nice.

[Duckle29]

Be aware that most scope probes have quite a bit of capacitance.
Usually around 18pF so would on their own load the circuit too much. Even our R&S 500MHz passive probes are 12pF.

For measuring crystals you really should have <2pF if not even lower and you don't really get that until you go to quite expensive ghz bandwidth probes