KiCAD schematics/PCB and PCB changes

Hi everyone,

After Camchaney uploaded the original PCB design (thanks a lot!), I made several modifications and converted it to KiCAD. While the design is still a bit rough and requires further refinement, I hope it can be useful to someone. Please note that I can’t guarantee its functionality, so it would be great if someone could double-check it.

A few key points to consider:

  • This version is not compatible with Camchaney’s sensor board. I changed one ground connection to 1.8V to allow for centralized power distribution to the sensors. I plan to use PAW3395DM sensors in my design.

Here are the changes I made:

  • Removed the 5V line
  • Eliminated the buck converter and created a separate PCB for voltage conversion using off-the-shelf buck converters from AliExpress/Amazon (please check the links; there are more affordable sellers on AliExpress).
  • Switched the resistors and capacitors to 0805 packages for easier hand soldering.
  • Replaced SMD electrolytic capacitors with through-hole capacitors for manual soldering.
  • Changed the sensor connectors to Molex JST XH and modified the power connections to Phoenix MC 3.5mm.
  • Adjusted the sensor connectors to supply 1.8V from the main PCB (this involved removing one ground pin). If you use Camchaney’s sensor boards, please be cautious it will short the sensor boards and the main board!!!
  • The encoder still needs to be positioned correctly, as it may not fit the control panel. There were some issues with converting the Eagle files.
  • I rearranged the pins on the stepper motor connectors to ensure compatibility with my stepper motors.
    I hope this KiCAD version serves as a useful starting point, but please keep in mind that it still needs additional work and cleanup.

teensy-jst_01.4_v9.zip (589.8 KB)

With large amount of EMI from stepper motors, it’s very possible that supply voltage could be swinging around outside of valid threshold… especially with these very low voltage I think local regulation with an LDO like on original boards is a more robust method for powering the remote sensor boards.
The sensors are also using separate Vccio (3.3V) for serial bus, if you only are bringing 1.8V over are you also doing level shifting on main PCBA? Or can teensy support 1v8 logic level IO on arbitrary pins?

Sweet, stoked to see that conversion getting started. I have been on my last nerve with Fusion. I am most certainly going to switch to KiCad for the next PCB iteration

I’m also a little concerned about this 1.8V line. The GND wires through the sensor connectors provide extra current paths to help minimize EMI. I would be partial towards doing the power drop on the sensor PCB side, just to make sure that voltage is as precise as possible. It goes directly towards powering the sensor’s illumination. There is some room to use a slightly different VDD for that line (such as 1.9 or 2V), but the LED resistor should be modified accordingly.

Thank you for your feedback. I was contemplating the use of shielded wires for the sensor connections, as they would also help with the SPI connection. However, you raise a good point regarding the VDD’s direct impact on the illumination of the sensor, which I hadn’t considered before.

The sensors support a maximum of 3.3V for VDDIO, so that should work well with the Teensy.

In my experience, EAGLE/Fusion can be quite user-unfriendly for PCB design. However, I have found KiCAD to be a solid option. It’s one of the few open-source software tools that’s widely used in the professional field, making it definitely worth learning.

Yuppp, in my experience as well. EAGLE was a lot better, but Fusion has introduced so many bugs. I’m very over it :upside_down_face:

I started out using shielded CAT8 wires, but it doesn’t seem to make a noticeable difference. In some cases it might’ve even made the SPI connection worse. We go deeper into the pros/cons and eventual choice of CAT5 cables in this thread

Yeah, unbalanced signals on twisted pair can be tricky. There’s more capacitance in a twisted pair than other forms of cable so you can end up with more crosstalk. That’s rough to deal with on an SPI connection because the data lines are read at a clock transition, so if that clock line disrupts the data lines at all then it can easily lead to corruption. That’s one of the things where UARTs or CAN can be more robust because they have some fancier options for dealing with those kind of issues, like oversampling with the UART or adjustable timing for when the states are read on CAN.

If you’re trying to go super long distances there are options like using transceivers to make the SPI into a differential signal but that gets pretty clunky if you’re doing it with a full bi-directional SPI link.

Some of that can also be adjusted by careful choices on which lines/pairs to use.

2 Likes

Do old versions of eagle still work? I liked it before fusion.

Yeah, when I was looking over ways to approach doing somewhat high speed SPI off-board, I initially just jumped to LVDS but found that managing the topology of that could be a bit more tricky than it is worth.
I think probably the best thing we could do without drastically changing the hardware is to isolate each sensor to it’s own parallel segment of bus using something like the TXU0304, so that there is not effectively several huge (300-500mm) antennas hanging off of the signal source at the Teensy. They are all tri-stated by the chip select pins so that multiple chips are not re-driving the same lines. I’m still putzing around with the design but here’s a bit of a sketch: (note: this is for an idea i had to try and run the compass off an STM32 part rather than a Teensy, so very WIP)

That’s a great question. Just from a quick google search It seems like EAGLE is still available, but will be completely discontinued in July 2026 :confused:

A lot of this goes over my head, but it sounds super cool hahah. Is this effectively reducing the capacitance of the SPI lines? I’m still a little confused what those chips are doing…

It’s splitting the lines into individual sections, each driven by their own buffer.

So rather than having say 300pF of capacitance on 3x paralleled SPI lines, you’ve now got 3x separate lines with 100pF each. The key there is that each buffer is now driving 1/3 the capacitance. How much this benefit this provides can vary quite significantly depending on the issues you’re trying to address.

If the buffers have negligible output impedance then it would have no benefit, the outcome would be the same. A 0V to 3.3V transition would have a nice fast edge rate because the buffer has enough output current to quickly charge the 300pF of capacitance. The cross-talk would be the same because the current impulse from the high speed edge on the neighbouring line through the capacitance would propagate down the line and into the driver without much voltage change due to the impedance, etc.

If the buffers were high impedance the improvement could be up to a factor of 3. Each buffer is now driving 100pF instead of 300pF so that’s 3x the high frequency impedance so 1/3 the current output requirement for the same edge rate, which means a faster transition from 0V to 3.3V with the same output impedance. Same thing with cross-talk, 1/3 as much cross-talk current means 1/3 the voltage disturbance as the driver sinks/sources that current. That’s a fair bit of an over-simplification, but hopefully it gets the idea across.

In reality it’ll likely be somewhere between those two situations. It won’t be a perfect threefold improvement in edge rates and cross-talk, but it’ll definitely be better. The downside, of course, being extra complexity, cost, board space, power consumption etc. as well as sometimes simply being not really possible without kludges that may make other things worse. That’s common with buses like SPI where you have to be able to have things like the slave device drivers go into high-Z output so that other devices are able to communicate. The network then needs a way to either know that the end device is in high-Z state and to do the same to the master-end buffer, or it needs a defined ‘idle’ state that can overridden by other devices, etc. It’s even worse again with stuff like I2C where you’ve got something multidrop with a high-Z idle state and low-Z active state. Then each buffer needs to be able to replicate that high-Z/low-Z state across it which can cause all sorts of issues. There are chips that do it but in my experience they haven a strong chance of introducing other problems/variabilities that can be remarkably difficult to diagnose.

Another way it helps is reflections, although that’s probably getting into a longer line/higher frequency consideration than your SPI links may need. As frequencies increase your wires start to behave as transmission lines, which basically just means that rather than thinking of it as a single inductor and single capacitor, it now looks like a string of tiny inductors and capacitors all connected together to make a series of LC ‘filters’. Once you get to this point, the high frequency components that make up your edge take time to propagate down the line because the voltage impulse at the start takes time to build current in the ‘first’ L, which then takes time to build voltage in the ‘first’ C, etc. all the way to the end. The energy that has been ‘waterfalling’ its way down the cable gets to the end of the cable and (in simple terms for an unmatched system) doesn’t have anywhere to go so the ‘final’ capacitor charges more than you expect and that energy then starts to flow backwards back to the start where it will look like a voltage spike when it arrives back at the driver, etc. With 3 lines all connected together, these pulses flow down one line then bounce back along the other lines, then return etc. They can be strong enough that they can cause the receiver to read an incorrect voltage in some cases, causing data corruption, or even damage to electronics in truly extreme cases. Separating the lines with buffers like this allows all of the pulses flowing around to be simpler and lower total energy, because you’ve got 1 reflection instead of 3, for instance. The other way to handle this is to have the transmission lines ‘matched’ by a terminator, which means that the impedance of the receiver is designed to be the same as the impedance of the transmission line, which means that when the energy impulse arrives at the receiver it all gets dissipated in the resistance of the terminator. Even if it’s not perfect, it’ll still usually be much better than nothing at all. That’s why with things connected by coax you’ll often see a standalone resistor to return near any receivers or transceivers. Same thing with ethernet or high speed differential signals. For stuff like DDR interfaces it starts to get even gnarlier, but that’s a bunch of steps beyond this again.

3 Likes

Eagle6 has been my go-to for years now, however I’m making an ESP32 (with some external multiplexers) version of this board to teach myself kicad.

The idea is that you can leave your laptop with the cad design on it somewhere clean and run the compass nextdoor in the workshop, either sitting on the same wifi access point or using the ESP as the access point

Better than I could have said myself! Thanks for the detailed reply!

2 Likes

Wonderful, thank you for the crash course Jono!

2 Likes

Here’s an incredibly useful article from Texas Instruments about extending SPI connections over long distances: Extending the SPI bus for long-distance communication

For optimal performance, using RS-422 for the SPI connection is likely the best approach.

Oh sweet! Lots of cool stuff in there. @jono035 helped me implement a few of those things into the circuit earlier on when I was debugging SPI connectivity. Series resistors for the data lines and RC filters being a couple of them that really helped with robustness.

RS-422 seems pretty awesome, but also it might be overkill at the moment. I haven’t really been seeing any issues with the current setup once the series resistors were added. I think the 400mm run (compared to the 100m runs they’re referring to in the article) won’t really have any noticeable issues in terms of synchronicity. The PMW3360 also runs at pretty slow clock speed

Yeah, I was just about to respond that differential comms is more about 10s to hundreds of metres. Sub 1m is pretty easy, SPI wise, it just may need some care to avoid the crosstalk issues above.

Certainly if you wanted to run things very remote than RS-422 transceivers are awesome.

Yeah for the compass it’s probably a little overkill, but with the noise from the spindle and the steppers it wont hurt to implement RS-422, not sure though if it is actually necessary. But the parts are pretty cheap and it will only add a couple of bucks to the BOM so if it makes the communication more stable and the machine more flexible (i.e. different spindles without testing etc.) it’s definetly worth it imo. Also it’s pretty easy to implement it on the pcb.

I’m not so sure… It basically means you can’t use ethernet cable as you’d need more than 8 conductors per SPI link.

I wouldn’t think the EMI from the spindle will be an issue unless it was already showing to be a huge problem in the prototype versions… Either way, with good general EMI practices I wouldn’t be so worried. We happily run SPI around in 100kW level power converters which aren’t exactly an electrically quiet scenario…

The stability of the SPI depends on a lot of factors though and is sometimes hard to predict in my experience. Also i. e. the better PAW3395DM sensor runs on 10 MGHz SPI Clock which also affects the stability of the SPI communication.

Making 1m of a 8 x twisted pair cable which should be enough for all sensors is also not a big deal imo and doesnt take much time.

RS-422 would make the whole machine more easily adaptable to different sensors, spindles etc.

One butched work piece because of some rare SPI communication error definetly costs more than to implement RS-422. Also they’re probably not a lot of compasses out there right now so we don’t have a lot of data how it behaves with different spindles, environments etc.