Board to board connections in multi-PCB project - Page 1
Forum section: electronics / projects

author: Trotters_Independent2
author_rank: Contributor
timestamp: July 23, 2024, 07:31:51 am
content: My team are entering into a competition which involves designing and building of a low speed electric vehicle. We are designing a multitude of different PCBs to implement things like telemetry, sensing of various voltages/currents/temperature etc and they all communicate with the main "CPU" PCB via CAN bus.I am hoping to make connecting the PCBs together as simple as possible and cut down on any “rat’s nest”, as we will likely need to disassemble the vehicle for transporting it and re-assemble it at the competition venue. I only really want a single cable, providing all the necessary power supplies and CAN bus between the PCBs. The cable is going to consist of multiple individually screened twisted-pair wires, all combined in one insulated cable, something like the below,see attachment: "03_Cable_example.png"I am intending to have each PCB fitted with two D-sub type receptacles, that way, the PCBs can simply be chained together with multiple-such short cables, fitted with compatible connectors at each end,see attachment: "04_Daisy_Chaining_Idea.png"These cables will probably not be much longer than 30cm each although there might be some exceptions.The PCBs communicate with each other via CAN bus. But I am aware that this board-to-board connection strategy means a few cm of unscreened, untwisted CAN traces on each PCB – and there will be up to 7 PCBs. The question is: would this be enough to likely cause communication disruption in the electrically noisy environment of a DC motor-powered electric vehicle with 150 of amps of traction power flowing? I will do my best to keep the distance between the receptacles on each PCB as short as possible – would criss-crossing the CANH and CANL PCB traces over each other through alternating trace layers in an effort to mimic a twisted pair wire, be worth it?I also expect there to be a fair bit of vibration so I am looking for a variant of D-sub that offers extra vibration resistance; can anybody recommend a good connector for this? It doesn’t really have to be D-sub, to be honest - I just like them.TLDR: We are building a low-speed EV, and the control electronics consists of multiple PCBs. I want to simplify board to board connection as much as possible, ideally combining power supply and board-to-board comms into a single cable with individually screened twisted-pair wires eg:"03_Cable_example.png". But the board-to-board comms is mostly done over a CAN bus, and my daisy-chaining idea(see attachment: "04_Daisy_Chaining_Idea.png")will unfortunately mean a few cm of unscreened/untwisted PCB traces for the CAN bus on each PCB – and there will likely be 7 PCBs total.My questions are:- Will the few cms of unshielded/untwisted traces on each PCB be likely to cause us CAN comms errors? Care will be taken to locate them as far away as possible from traction supply cables, the DC motor and the motor controller - but at this stage cannot guarantee exactly how far. If it could be a problem, could routing the CANH/CANL traces in a criss-cross pattern in alternating PCB layers (in an attempt to mimic a twisted-pair wire) help?- Could there be other potential pitfalls to my board-to-board connection method that I haven't thought about?- Can anybody recommend a rugged and simple connector for us to connect our boards together? I was intending to try and find a vibration-resistant variant of D-sub but I'm not sure. Ideally, we want it to be at least 8-way.

author: wasedadoc
author_rank: Super Contributor
timestamp: July 23, 2024, 08:04:40 am
content: D-subs can have locking screws. Would they not stay together long enough?

author: Trotters_Independent2
author_rank: Contributor
timestamp: July 23, 2024, 08:21:38 am
content: I'm aware that they do have locking screws, but I am honestly not sure - not because I think they aren't good but because I don't have experience dealing with vibration. I just want them to be vibration resistant enough so that we can connect them up and forget about them indefinitely.In my head, I think that the locking screws could potentially work themselves loose and there ideally should be an alternate latch-based locking mechanism. I am not very "mechanically" minded, if I'm honest.

author: ch_scr
author_rank: Frequent Contributor
timestamp: July 23, 2024, 11:07:33 am
content: Just put low-strength threadlocker (e.g. Loctite 222) on the threads - literally made to prevent them from backing out due to vibration, while still allowing easy removal.

author: moffy
author_rank: Super Contributor
timestamp: July 23, 2024, 12:40:42 pm
content: One problem with daisy chaining a CAN bus is that a single failure will bring down the entire bus. If possible, separate out non critical items and give them their own bus while keeping critical items separate.

author: squadchannel
author_rank: Frequent Contributor
timestamp: July 23, 2024, 01:14:18 pm
content: It may be too late to say this now, but daisy chaining is a very bad idea. In the PC world, there was a bus standard called "SCSI" in the past, which was used to daisy chain CD and HDD drives, but compatibility problems occurred, and if a cable was bad somewhere, the subsequent devices were not recognized correctly.The best way is to put the control system on a single board and concentrate the cables for sensors and motors there.However, this is not the reality. Even in modern cars, various "ECUs" are installed depending on their roles and locations, and they are connected by CAN and other buses.There is a difference between your idea and the way the CAN bus is wired in modern cars.We do not install IN and OUT connectors between boards. It is simply "branched" from two differential CAN wires.This way, it is less likely that the wiring between the boards will be damaged or disconnected between the IN and OUT connectors on the boards, thus cutting off the CAN network.What I would do is to install one CAN bus connector from the "main ECU" and then make a "junction box" for the CAN of each control ECU. This way, you can be sure that nothing will go wrong and everything will not be ruined.D-Sub connectors are fine, but D-Sub is not suitable for outdoor use. It is inferior in terms of vibration resistance, etc.You may want to look at TE Connectivity's catalog of automotive and industrial connectors.I recommend M12 connectors.In my country, Japan, there is a competition where high school students build robots and compete, and it is broadcast on TV every year, but it is clear that all the teams are sloppy in their wiring.In fact, due to sloppiness, I often see teams misorienting connectors and damaging circuits, or spending hours debugging them because the connectors are not caulked properly.Connectors and cables are the first places where people easily assume that there will be no problems. Take care.

author: Trotters_Independent2
author_rank: Contributor
timestamp: July 27, 2024, 12:28:07 pm
content: Quote from: squadchannel on July 23, 2024, 01:14:18 pmMany thanks for your detailed reply.I will take your and others' advice about this and instead of daisy-chaining, I will instead use junction boxes to connect more CAN bus nodes.

author: max_torque
author_rank: Super Contributor
timestamp: July 28, 2024, 08:52:48 pm
content: Quote from: Trotters_Independent2 on July 23, 2024, 07:31:51 amok, hate to be the one to say it, buy why??? There ARE some very valid reasons to have seperate control units, mostly due to physical location constraints or for signals that cannot easily be moved (well less easily moved that a databus + power).Unless you are doing something EXTREMELY complex, then i see no reason that a modern 32b micro cannot have pretty much everything on-board it needs to have. You can still have teams designing the different sections (i do this all the time) and with modern EDtools co-operative design can occur at all levels (schematic, board layout and 3d mech).I'v got 30 odd years of direct electronics experience in motorsports (up to and including f1) in OE pass car and in aerospace and defence, and i can tell you right now "avoid every connector you can"!If you have to have entirely seperate pcbs, then look at stacked arrangement (using automotive rated board to board connectors) or thesed days, more likely a "folded" arrangement using flex-rigid pcbs.This approach also massively cuts down on both overall software complexity (because 1 processor is in charge and can use all it's direct perhipherals) but it also minmises the diagnostic NIGHTMARE that multiple external controlelrs connected over a relatively vunerable network brings (if you sit down and do an FMEA, even in a non-critical space (ie not ISO26262 etc) you'll see the inter-dependability matrix quickly spirals out of control, especially for a small team, and ime, especially for a small team who would much, much, much rather do the fun stuff than wade through thousands of hours of diagnostics coding and validation........If ECUs are external, then they need to be fully external ie to have their own power supply (with the necessary protection and filtering) and IP / environmental protection, and to have suitable automotive rated enclosures and connectors. Here, there is plenty of choice, although somewhat expensive at low volumes. Picking a "standard" enclosure, for example the Deutsch TE enclosures means you can design one single pcb (physically) with a standard power supply section, a standard coms section, probably a standard logic section, and simlpy add the custom IO around that to suit the particular application need. At low volumes, using the same part multiple times is an absolutely huge win in terms of COST and BOM minimisation, and allows you to reuse as much code as possible (for example a single CCP / XCP / UDS diagnostic stack for CAN reprogramming and external monitoring can be written and used for EVERYTHINGI have great success with a deisgn that uses exactly this arrangement, with these TE enclosures:And i have a standard "Base board" that has all my standard bits on them (PSU, COMS, Micro etc) and then i route pins from both the application pcb header (12w or 24w for the smaller enclosures listed) to an internal board to board header, and i route various pins from the micro to that header as well. So i have a base board that can be fully proven and standardised, and say i need a module that reads a load of thermistors and spits the data out on CAN, i simply design a custom "application specific" internal board, that sits on the b2b header and does just that, in this case, have some thermistor drivers and some IO filtering and protection and then route the analogue signals to the appropriate pins on the micro.These days where the vast majority of micros have multiple pin allocations and peripherals tend to be able to be "remapped" this tends to work really easily. My low level code is therefore identical, and can be reused and robustly tested, so this approach is an interative approach rather than a breakway approach.

author: max_torque
author_rank: Super Contributor
timestamp: July 28, 2024, 08:57:58 pm
content: And appologies, but i'm going to say it again:"AVOID WIRING AND CONNECTORS LIKE THE PLAGUE ITSELF"ALL your problems will be these items, and every manually made node or interface is a protential mistake, and the vast majority of your teams time will be spend making harness, connectors, and debugging those and trying to find faults in them! By comparison, a modern multilayer pcb is just about the most reliable device ever invented and pretty much never is a fault item these days (assuming it's been deisgn and tested properly...)

author: jonpaul
author_rank: Super Contributor
timestamp: July 29, 2024, 09:58:31 am
content: " Low speed electric vehicle"Rethink use of CAN bus, lots of traps there.D Sub are for indoor/non vehickle use . Just lots of issues.Find waterproof circular locking conneector see Cannon, HiRose, Amphenol.Check the transient suseptibilty of your system design and protoAny speedf vehcle had safety and liabiulity issues, (especially EV)Advise find compliance expert and buy liability insurance.Bon chanceJon

author: Trotters_Independent2
author_rank: Contributor
timestamp: August 01, 2024, 08:24:58 am
content: Quote from: max_torque on July 28, 2024, 08:52:48 pmThe reason why is more of a "project management" type reason. Having a single centralised "controller" was the initial preference. But we are a geographically displaced team living in different cities, with limited opportunities to meet in person, and each of us with very limited time and experience - except myself with some electronics design experience but no prior management experience.Having a single controller with all (or most) of the features combined into one PCB would mean too much work for an individual person (namely me) and I felt it would be difficult to get a whole team of several engineers working on one PCB. I feel the multi-PCB method makes it easier for everyone to work on their own bit in isolation, develop software, debug hardware etc. They can set up a dummy central controller at home to mimic the CAN comms that will be happening when the individual PCBs are installed into the main system and they can validate that their own PCB works exactly as intended. And it clearly sets implicit boundaries between each others' responsibilities, even if overall system complexity is somewhat increased.That being said, I am autistic and struggle with management and organisation in general so there could easily be another approach that I haven't thought of, but this seemed like the best way to manage the team's work and develop a solution, given our circumstances.

author: max_torque
author_rank: Super Contributor
timestamp: August 01, 2024, 12:11:27 pm
content: Quote from: Trotters_Independent2 on August 01, 2024, 08:24:58 amI can see why you might think the "Multi-controller" approach is easier and less work. But, it isn't. What it does is open you up to everyone elses faults/bugs and errors bringing down the show, and your software task is multiple times bigger because everyone has to do all of their own s/w for each node, and some one has to do the "integration" and "network" software. More work, more potential for errors and bugs.My suggestion, is as follows:1) choose a decent microcontroller for which you can get a dev kit/devboard. This isn't hard these days, plenty of choice. That controller can be an "overkill" for individual requirements, but it's cost is pretty much irrelevant in the grand scheme of things2) One person, most familiar/experienced with that micro is responsible for building the "low level code", a standard set of code files that allows the peripherals to work on the dev board as required. These days, thanks to things like STMcubeIDE etc, this task is pretty trivial, ie you can build a low level environment pretty much entirely with "clicks" for most micros. The days of directly manipulating registers and setting up periferals by hand are (mostly) long gone3) Each person then develops their part of the system for their specific I/O and task using that dev board as the standard logical element. The "team manager" will need to track and allocate microcontroller resource and peripherals to avoid conflicts, but this is pretty easily done. This gets you up and running very quickly indeed, as each team member can get coding and developing pretty much straight away.4) once you start to see how things are forming, in terms of physical size and uC resource allocation, the team manager can now start to look at issuing each team member with a standard "footprint". The form factor is up to you, but lets say you use 100mm x 100mm square pcbs, linked with stackable ribbons or direct board 2 board connectors. Each team member can take their protoype circuitry they proved with the microcontroller dev board and very easily port it across to the final physical design package.5) Whilst this is going on, the team manager takes the dev board basic circuitry, and puts it onto the projects "base board". Here you can pretty much copy the dev board, although for auto rating you'll need to look at psu / emc / filtering etc This board should also deal with suitably robust I/O connectors out into the real world, these might need to be on flexpcb or ribbons depending on your mech design6) Finally, one person can take each team members proven and working code + header files and put them together, so one micro on the base board can do everything.At a bench test level, you can do an intermediate step, where you run a full or partial system using the devboard itself and a rats nest of wires to each team members I/O circuitry proto boards but don't be tempted to put this in the vehicle, trust me, it won't work and it will introduce so many problems and faults, and consume so much of your time chasing "Ghosts" you'll wish you didn't bother!I'll guess you are budget limited and have few contraints in terms of space or mass, so there are probably no prises for making everything small and sexy. Get a big box (ideally an COTS automotive rated ECU enclosure with integrated connectors (as linked previously) and just put all your individual pcbs in their.

author: tooki
author_rank: Super Contributor
timestamp: August 01, 2024, 05:22:57 pm
content: In terms of connectors, you can use d-sub, but if you do, use only top-quality ones with machined contacts. This needn’t even be that expensive; Amplimite housings and mil-spec crimp contacts (M39029/63-368 female and M39029/63-368 male) combined with a good backshell is adequate for many situations that don’t need weatherproofing.But there’s a reason that one-off cars (like race cars) and aerospace use a lot of circular connectors, despite the high cost: flexibility and reliability. There’s a huge selection of weather-sealed versions, variations on backshells and seals and accessories, as well as interesting contact types that allow you to mix regular pins, coaxial, fiber optic, and even pneumatic connections by inserting different contacts.Take a look on YouTube for how race car harnesses are made. They’re things of beauty.As for integration: developing different sections independently can give you some advantages (especially in terms of being able to completely replace a section easily if it doesn’t work), but as others have said, the system integration complexity is at least as large as in doing it as one board, if not larger. IMHO to be successful, you still need to have very clearly defined the system architecture and above all the interfaces between the sections — and you need to do that before you begin designing anything. Otherwise you just end up with individually-functional modules that can’t talk to each other properly, or don’t actually do everything they need to do.

author: max_torque
author_rank: Super Contributor
timestamp: August 01, 2024, 07:04:05 pm
content: Quote from: tooki on August 01, 2024, 05:22:57 pmHonestly, this is also the case with doing it "all on one board" these days! And honestly again, on a project like this one, you shouldn't even be looking to combine subsections in ANY way until you know they work. Thanks to circuit simulation, it's unlikely anything you are doing on a car is complex enough to be likely to "not work" (unless you are doing AI driving etc...) Sure, some component values might need a tweek to say remove some noise, or a bit more analogue filtering added to clean up a signal, but really, most of your work in going to be in the software domain (i'm going to assume you are buying a COTS motor controller, not rolling your own, if you are, good luck, this IS a serious task...)Take reading some thermistors. It's pretty easy to identify you'll need some ADC peripheral access on the micro to convert the analogue signal to digital, and some I/O circuitry to drive, filter and ideally diagnose the sensor itself, but none of that is very hard. What you get however is a robust solution, where one failure is much less likely to remove an entire chunk of data (a CAN Bus is a "constriction" in the system, both in terms of throughput, but also in terms of a failure node where one failure can have extremely far reaching impacts. A single board, or well physically coupled multiple pcbs sending data to one controller is much more robust to failure, and a single failure is likely to be less catastrophic (and you failure matrix becomes a lot simpler)So you get your "thermistor team member" to start simulating, then designing a proto pcb to plug into the standard devboard you have choosen, so they can quickly get up and running, testing and developing, and not worrying at all about the size or physical constraints of that individual part. They can make their IO test board as big as it needs to be, with test points, and plenty of abillity to "fudge in" say an additional resistor or ferrite bead or whatever. They can write the software to read / process and respond to their stimuli, and get everything working. At some way into this process, the team leader can start to look at his team memebers sections, and start to pull together an overall single system design. The final re-spin to move from the prototype IO pcbs to this new single solution is really pretty simple, and while he waits, the team principal can get started on the power and logic elements to the controller, and the 3d design of it (which is critical to get right in the auto sector)