What if the biggest challenge in electronics today isn’t the technology itself, but how we design, integrate, and manufacture it?
In this episode of the The Engineering Triangle, Ayrton sits down with our embedded team leader Xarion Comoretto to explore the hidden challenges of electronics design, IoT development, and rapid prototyping. They break down why so many projects fail due to poor design choices, how the right toolchain can save months of engineering effort, and why engineers must strike a balance between first principles and practical problem-solving.
They dive into the evolution of PCB and enclosure design using Altium and SOLIDWORKS, showing how modern integration is cutting down development time. The discussion also covers the power of open-source tools like KiCad and how they are shaping the future of electronics. They tackle the challenges of AI-driven automation, the complexities of bridging software with physical systems, and the importance of working within an established ecosystem to avoid costly mistakes.
From avoiding common design pitfalls to building robust IoT solutions with the Cranio Pro-IO ecosystem, this episode is packed with insights for engineers, product designers, and innovators looking to push the boundaries of hardware development.
For those who would rather read than watch or listen, here is a polished transcript of their discussion!
Ayrton: Hi, and welcome to The Engineering Triangle, our podcast about making the best smart machines and IoT as fast as possible. I’m your host, Ayrton Sue, here at Element Engineering Australia. Today is all about electronics design. We’ll cover the tools we use, like Altium, as well as best practices from our experience.
I’m here with Xarion Comoretto, an experienced electronics engineer who heads up our embedded team at Element. Thanks for coming on!
Xarion: Thank you.
Ayrton: Electronics design, for me, is like my second engineering wind. I started off in mechanical, but with my background in data acquisition and logging, I began making my own circuit boards around 2010–2012, working within the Arduino ecosystem. I hit the limitations of different Arduinos, so I started making my own circuit boards using those chips.
Over the years, I’ve probably done five to ten years of hardcore electronics work. I’m by no means an expert, but I think I’m pretty good in some areas—analogue design and RF, in particular. But electronics is such a massive, broad field.
Xarion: Unlike you, I started from the basics—logic PCB design—rather than working with something like a Raspberry Pi, which already has everything built in. My fundamentals were really simple, starting with little counters using logic, shift gates, AND gates, and OR gates.
Ayrton: Yep, yep.
Xarion: That was my introduction to electronics. Naturally, you need to do more—you can’t just be counting forever. So I started programming some code and designing more complex circuits.
Ayrton: Yeah, I think I was a bit later than you. Going even further back, I started with Dick Smith Electronics kits. For those who don’t know, Dick Smith was an Australian brand—he had a shop similar to Jaycar or Altronics today. You’d go down there, buy resistors and components, and they had these beginner books where you’d follow along and build circuits on a protoboard.
Xarion: So you had a reference design to follow.
Ayrton: Yeah, the first circuit I built was a simple flasher using a transistor.
Xarion: A lot of those circuits are still useful today. You don’t need a microprocessor just to flash an LED.
Ayrton: Absolutely.
Xarion: Many of those circuits are still relevant.
Ayrton: Things like 555 timer circuits.
Xarion: Exactly.
Ayrton: Those kits were actually what got me interested in electronics engineering. But I couldn’t see the applications at the time. When I went to university, I saw the mechatronics engineering degree, but back then, people said, “No one’s ever going to use mechatronics. It’ll always be either mechanical or electronics.”
Xarion: Yeah, they expected you to pick one or the other.
Ayrton: But now, if you’re doing purely mechanical engineering, you’re missing out on a lot, especially with where the world is headed. So I got into electronics and then some firmware and web software through necessity—just to do smart things for our business. And I love it. But it’s a real skill and an art to do it well.
Xarion: I almost didn’t have a choice—I was born into electronics. My father was an electrical engineer. He didn’t force me into it, but he strongly persuaded me to follow in his footsteps. It worked out well because I had access to all the tools. I didn’t have to buy components from Jaycar—I could just pull from thousands of little drawers full of resistors, capacitors, and logic gates.
We even made our own PCBs back then, doing the whole process—negatives, positives, exposing them, etching with chemicals.
Ayrton: Was this part of your family business back in South Africa?
Xarion: Exactly. The company has been around for over 40 years, and it started with custom electronics design for various clients.
Ayrton: That’s similar to what we’re doing here.
Xarion: Exactly. But we handled everything—PCB manufacturing, assembly, firmware, and full turnkey solutions.
Ayrton: That’s amazing.
What Makes for Really Good Electronics Design?
Xarion: The best electronics projects are the ones that are designed specifically for their intended purpose. The ones that really stand out are those you actually see being used in the field. When you walk around and see a device you designed in action, it is a real feather in your cap.
I find that if you focus too much on designing just for one narrow application, particularly in the IoT space, you can really limit yourself to a small market. Many IoT products have the potential to evolve into something completely different. You can change the software while using the same building blocks and suddenly you have a completely new product.
Ayrton: When we talk about IoT, we are referring to the Internet of Things. At the core of most electronics in this space is a microcontroller, which is essentially a small computer. It is probably equivalent in processing power to a 1990s PC but can perform a massive range of different tasks.
Each of its pins, whether there are 32, 144, or even 256 of them, can usually be used in multiple ways. For me, IoT is a lot about sensing and automation in an embedded way rather than using a PLC. When we say embedded, we mean the microcontroller is handling electrical signals in real time at very high speeds. Those pins can be configured to read sensor data, control actuators, or communicate with other chips and computers.
Electronics can be a learning curve. When I first started making my own data loggers, I had to figure things out the hard way. You often run into bugs or gaps in the datasheets, and you only find the errata buried a thousand pages in. But once you go through that process, you gain a deep understanding of what the hardware is capable of. It also gives you the ability to refine your approach and iterate on designs more efficiently.
Xarion: You also have to know when to stop. It is easy to get carried away with design and want your product to do everything. But you need to set a ceiling and know when to call it done. You should aim to make it as flexible as possible, but within reason.
Ayrton: Within a certain timeframe and budget.
Xarion: Exactly. Dream a little, but don’t go too far. Do not limit yourself unnecessarily, but at the same time, do not design something so complex that it never gets finished.
Ayrton: Some of the commercial products I have worked on include ShockWiz and TyreWiz. More recently, we have been working on the Koodaideri HydraTune project.
ShockWiz was a project I was really involved in. It was a fairly simple device, and we had great input from several people. In the end, we created a product that has remained unchanged for years. We never had issues with it on the production line, and it has performed really well. I would call that a success.
TyreWiz, on the other hand, was a much harder project because we could not use an off-the-shelf Bluetooth module with its own antenna. We had to design our own tiny 0.3mm BGA antenna.
Xarion: So you were working at the chipset level.
Ayrton: Exactly. We also had a constraint on the circuit board thickness, which made RF traces particularly challenging. That board went through multiple iterations to get it right.
Xarion: In RF design, they say the first thing you should do when designing a PCB is to place the antenna first.
Ayrton: Absolutely.
Xarion: You should not start by placing all the other components and leave the antenna as an afterthought. The antenna is the most critical part of an RF circuit, so you need to nail that design first and then build the rest of the circuit around it.
Ayrton: We did not do that well at first. We had a constraint where all the components had to be on the underside of the board, but the antenna needed to be on the top.
Xarion: So you had to change your approach.
Ayrton: Exactly. We had to place the antenna on the top side because the board sits inside a metal rim, whether aluminium or carbon, which would have attenuated the signal. If the antenna had been placed on the underside, it would have had terrible radiation properties.
Xarion: Because it would have been too close to the metal.
Ayrton: That is right. We had to place the antenna on top, which meant running a via through the board, which is usually a no-go for RF design. You can do it, but you need to characterise it properly.
Xarion: Then you have to match it and go through the full tuning process.
Ayrton: And we did. We had to carefully design the antenna routing for our thin multi-layer circuit board. I think it was a six-layer board, maybe four, I cannot remember exactly. We then used our VNA equipment to match everything properly. It was a fun challenge.
Xarion: It is incredible how even a 0.6mm change can make a huge difference in RF design.
Ayrton: Absolutely. That is probably the best example I can think of from my own experience. But you have worked on more commercial products than I have. What stands out for you?
Xarion: I find that good designs are also the ones that your peers can understand.
If you design something in your own little bubble, it becomes really difficult for anyone else to pick it up and work with it. I have learned from experience that you need to design things in a way that makes them easy for others to take over.
That means having the right comments in your code, the right documentation, and a clear structure.
Ayrton: And making sure your schematic is well organised.
Xarion: Do not just slap something together to get it done quickly. There has to be a long-term vision. If someone else needs to modify or troubleshoot the design, they should be able to do so easily.
Ayrton: It is about true collaboration.Good engineering comes down to how well you communicate with others. If you are working alone, that is fine. But if you are part of a team, you need to make sure that your work is easy to understand and hand over.
Xarion: Version control is also critical. You need to document the history of design decisions because that information can get lost over time as people come and go.
Ayrton: A top-level schematic should always be designed in blocks, so you can see the whole system at a glance. Then each block should expand into a detailed schematic showing exactly what is going on.
Xarion: That makes it much easier to navigate, rather than trying to cram everything into one page with wires running everywhere.
Ayrton: Exactly. Breaking things up into logical sections makes it easier for the whole team to understand. It also helps when handing things over to the software engineers, because PCB design is only the beginning of the process.
Xarion: That is right. Once hardware is designed, it needs to be integrated with firmware and software, and that process is much smoother when the hardware has been well-structured.
Ayrton: Good engineering really comes down to communication with others. If you are working alone, unless you plan to complete the entire project from start to finish yourself, you need to structure your work in a way that others can easily understand and build upon.
Xarion: Version control is also essential. You need to document what is going on and why certain decisions were made. That history often gets lost as different people work on the project over time. Keeping detailed records is crucial for maintaining a solid design.
Ayrton: A top-level schematic design lays everything out in blocks so you can see the entire system at a glance. Then, when you dive into each block, you can see exactly what is happening inside. For example, on the left-hand side here, we have up to 14 different sheets of the schematic, each representing one of these green building blocks. You can see labels like microcontroller, PWM outputs, and analogue outputs. Each of these refers to a…
Xarion: Its own sheet. Absolutely. It is much easier to view things in separate sheets rather than trying to cram everything onto one page with wires running in every direction. Breaking it up makes it easier to navigate. If you are looking for something, you can return to the top level, scroll around, and find what you need quickly.
This also makes it much easier when handing designs over to software engineers. PCB design is only the beginning. The software team needs to understand how everything is structured so they can integrate it properly.
Ayrton: Yeah, absolutely. If we look at the analogue input schematic, there is a note in the top corner. We add a lot of these notes to our schematics to document key decisions.
Xarion: Just small notes.
Ayrton: Exactly. The goal is to clarify why we did things a certain way. I recently reviewed an old schematic for a client, and some of these notes were missing. That meant I had to go back, examine the circuit, and figure out why a particular resistor was used—say, a 10k resistor on a configuration pin that limits current to 3.6 amps.
Without a note explaining that, I had to reverse-engineer the reasoning, which added unnecessary time and cost for the client.
Xarion: A simple note could have saved all that effort. Even something as basic as referencing a circuit simulation can explain why certain values were chosen.
Ayrton: These schematics are much cleaner than anything I used to do in the past.
Xarion: If I compare this to where I started, it is a massive improvement. Having pride in your work makes a big difference. It is easy to just throw something together and make it work, but a well-documented, well-structured design shows professionalism and makes life easier for everyone.
Ayrton: One of the key challenges in electronics, which is quite different from mechanical or software engineering, is the turnaround time when something goes wrong. If there is an issue with the board, it can take anywhere from six to twelve weeks to identify and fix it. You need to manufacture a new circuit board, source the chips, have someone place the components, and then wait for it to come back. After that, you have to run a smoke test to see if anything burns out.
Xarion: And even then, you still have to send it to the firmware team. They will go through it, and if something does not work, it gets sent back to the hardware team. Then you need to figure out whether it is a firmware problem or a hardware issue.
Ayrton: Or it could even be a manufacturing fault, like a bad solder joint or a misplaced component. That is why we refine our schematic sheets so carefully over multiple iterations. But the reality is, electronics does not have a fast turnaround. With software, if something does not run, you immediately see the error, fix the code, and move on. It is instant feedback.
Electronics is the exact opposite. There is a massive lead time.
Xarion: You have to go through the full process—get the board manufactured, assemble all the components, and apply power before you even know if it works properly.
Ayrton: Another factor is that even if you simulate the design on a protoboard, placing it onto an actual circuit board introduces new complexities. Things like the physical layout, soldering, and trace routing all come into play. They are not huge challenges, but they do add an extra layer of complexity.
Xarion: And that is why there is always pride in your work. You do not just throw components anywhere on a board. There are some really beautiful PCB layouts out there. I think only an engineer can truly call a PCB beautiful.
In your last podcast, you mentioned starting in 2D. PCB design has traditionally been a 2D process, but now we integrate a lot more. You can bring in the 3D models of the enclosure, include the 3D shapes of the components, and see exactly how everything fits together. This allows you to make sure your keep-outs are in place. For example, this green part here is the aluminium…
Ayrton: Housing.
Xarion: Yes, the housing.
Ayrton: Can you switch to the 2D view and show us the routing? To a mechanical engineer, this would look like a complete mess. And to be fair, it is.
Xarion: My wife calls this the traffic jam. Moving components around on a PCB is like that puzzle game where you slide cars to clear a path.
Ayrton: I have no idea which game you are talking about.
Xarion: I think it is called Rush Hour. You can spend hours trying to optimise a PCB layout because one component just does not fit where you need it to.
Ayrton: I remember my first data loggers in a Deutsch box, working with BGAs where almost every pin was used. You would fan everything out, place the components, start routing, and get about 80 percent done before realising there was no physical way to complete the layout. Then you would have to start over, reroute everything, or add more layers, which adds more complexity.
Xarion: And then you have that moment where you think, what if this could also do this?
Ayrton: Yes, exactly.
Xarion: And of course, the pin you need is buried right in the middle of the board. To access it, you have to shift everything else around. It is like solving a puzzle.
Ayrton: It looks chaotic, but there is a method to the madness.
Xarion: This particular design is an eight-layer PCB.
Ayrton: So we have two ground planes, two power planes, and four routing planes.
Xarion: The layer stack-up is always important. You have to carefully decide which layers will be used for power and which for ground.
Ayrton: And that is usually dictated by the PCB manufacturer you are working with.
Xarion: Yes, and you also have to consider electromagnetic interference (EMI) and certification requirements. The number of layers you use impacts compliance and performance. These days, you are not restricted to two-layer PCBs. Moving to a four-layer design does not double the cost—it has become standard practice to avoid two-layer boards for complex designs.
Ayrton: I completely agree. The price difference is minimal, and a four-layer board is so much easier to route compared to a two-layer board.
Xarion: With four layers, you get a solid ground plane and a solid power plane. You do not have to compromise signal routing just to accommodate power traces. You can dedicate one layer to signals, one to power, and one to ground.
Ayrton: Exactly. Just spend the extra two dollars.
Xarion: Yes, just pay a little more, and you end up with a much more reliable board. Better heat dissipation and overall better performance. When you try to stick with two layers, you often find yourself constantly switching between them, which adds unnecessary complexity. It is much better to make the jump early, keep the layers organised, and focus on a cleaner design.
Ayrton: Some of the more complex boards I worked on, particularly my early data loggers, were around 10 layers with BGAs and everything packed tightly together. I found that the top and bottom layers were mainly used to position components and get the traces out to where they needed to go. Then, as you moved deeper into the board, certain layers were dedicated to vertical routing, while others were for horizontal routing.
You would end up creating patterns where, if absolutely necessary, you could take a signal from a pad, drop it down to the next layer, route it vertically, drop down another layer, route it horizontally, and then bring it back up. It was not ideal for EMI or other considerations, but for high-density interconnect boards, sometimes you had no choice.
Xarion: If you have complementary pairs, it is much easier to keep them on their own dedicated layer. That way, you avoid weaving in and out of other stuff, trying to dodge obstacles while keeping the lengths matched. These days, multi-layer designs are just standard practice.
What about bad electronics design?
Xarion: I have definitely done some bad designs.
Ayrton: I think we all have!
Xarion: It happens when you think you are God's gift to the electronics industry, convinced that you will get everything right the first time. You rush through the schematic, lay out the PCB, and feel so confident that you send it off for manufacturing. Then it comes back, and you realise you have forgotten the programming header. That is why having a review process is so important. Someone else needs to check your work because no one gets everything right alone.
Ayrton: We have an engineering checklist that we go through now to make sure we have covered everything and met all the requirements. I have had plenty of designs where something was wrong, either in my schematic or on the PCB. The moment you power it up, something gets red hot and starts burning out.
How do you handle the smoke test? Every electronics engineer I have worked with does it. The goal is always to keep the magic smoke inside. That first board—the golden prototype—costs a lot of time and money. So if something starts burning out, you need to remove the faulty component quickly to save the rest of the board. That way, the firmware team can still use it, and you can continue refining the design in parallel.
Xarion: In the old days, there was no direct link between the schematic and the PCB. You would design the schematic first, then the PCB separately, with no automatic cross-referencing. That is where I saw the most smoke coming out of boards.
You had to manually go through every pin, check the datasheets, and make sure everything was correct. Now, with modern tools, you cannot connect a pin incorrectly unless the component itself has been designed incorrectly. This has reduced the number of smoke tests significantly.
Most failures these days come from mechanical issues—things like a solder bridge, too little solder, or poor grounding that prevents proper heat dissipation. One simple way to prevent damage is to limit the current on your power supply the first time you power up the board. If you see the current spiking, switch it off immediately and start troubleshooting.
Ayrton: Yeah. How do you usually check for hotspots? I used to just use my fingers.
Xarion: It depends on how fast it happens. Sometimes, when designing circuits, I like to use zero-ohm resistors to connect power rails to different sections of the board. That way, you can isolate different parts easily.
Ayrton: Zero-ohming was a hard lesson for me. Using a zero-ohm resistor on a power rail lets you turn on different subsystems one by one, simply by soldering the resistor in place.
Xarion: If you are designing the first iteration of a product, do not try to squeeze everything into the final enclosure straight away. Design everything with extra space so you can properly test power, current, and functionality.
Ayrton: And then miniaturise later.
Xarion: And then scale it down. Otherwise, you waste a lot of time. When you try to make something small too early, you end up doing unnecessary extra work and making compromises that are not needed. Your first iteration should be purely functional, just a proof of concept to make sure everything works.
Ayrton: In the past, we used to make what I called frankenboxes. We are very lucky these days because companies like SparkFun, DFRobot, and Adafruit make it much easier to get started. Having access to these small demo boards means you can wire everything together with hookup wire and test your circuits before committing to a design.
You would start with a protoboard containing just the custom circuit elements that are unique to your project. That way, you could do most of your development work at this stage before moving on to the next step.
Xarion: It might look terrible, but that does not matter.
Ayrton: Exactly, as long as it works. I have even seen some products go to market in this form, literally just proto boards mounted onto a small carrier board. The next stage is taking those circuits and putting them onto a proper protoboard layout.
Xarion: It really depends on scale. If you are only making 50 units, you might as well use off-the-shelf modules. But if you are producing thousands, there is a significant cost saving in taking whatever is on those small boards and integrating it directly into your own design.
Ayrton: That way, you are not paying for someone else’s profit margin by including their pre-made board in your product. But it depends on the application, different approaches suit different projects.
One of the times I ended up letting the smoke out was due to incorrect pin assignments on the chip itself. The schematic was correct, but the pin positions were wrong on the actual package. This is especially tricky with components like SOT-23 transistors, which can have different pinouts.
Xarion: When designing a component, always check the package carefully. The physical layout may look identical, but the pin arrangement can be completely different.
You might think it is a standard SOT package, but it turns out to be a UFN, and you have just assumed…
Ayrton: You’re giving me nightmares, I’m getting flashbacks!
Xarion: You just assume they would have used the same pinout.
Ayrton: That is exactly what happened to me with one of my first datalogger designs. I had it manufactured by a company in Adelaide, and they called me up saying, We don’t think this one is right.
Xarion: This footprint does not look correct!
Ayrton: And I was like, Oh, just fit it. Then, of course, you get it back, power it up, and the smoke comes out. You save the board, pull the components off, and in that particular case, I was able to just rotate it 120 degrees and get it to work.
Xarion: Was it a three-pin device?
Ayrton: Three-pin device, yeah. Just rotated it. It was magic. Otherwise, I would have had to flip it upside down and bend the legs.
Wire modding is almost always necessary at some point. Lately, we have had really good success, with most of our boards coming back working 100 percent.
Xarion: By the time the board is made, at least three people have reviewed it.
Ayrton: But wire modding is nothing to be afraid of, and there is no reason to be embarrassed about it. It is a common practice. If you have spent weeks or even months designing a circuit board and something is not quite right, you just wire mod it, bypass the issue and make it work. Even a partially working board is valuable for testing and development.
Xarion: You will find a lot of wire mods inside Wi-Fi routers.
Ayrton: Really?
Xarion: Sometimes you open them up and think, Huh…
Ayrton: And then you realise, This went into production! This is being sold in big-box stores.
Xarion: And they are making thousands of them, not just ten.
Ayrton: That makes me feel a lot better.
Xarion: It happens everywhere.
What Software and Tools Do You Use for Electronics Design?
Xarion: Electronics design cannot happen in a vacuum. You cannot just focus on PCBs and schematics without considering the bigger picture.
First, you need to understand what the device can actually do. What functions can those pins perform? With modern microcontrollers, you can move things around easily. If you do not want the UART on one side, you can shift it to the other without much trouble.
What usually happens is that after laying everything out, you realise that if you just move a couple of pins, your traces will run much cleaner. Since they are general-purpose I/O (GPIO) pins, it does not matter functionally. But by making those small changes, you avoid unnecessary layer changes and make the design look much neater.
When we design something, we always have the integrated development environment (IDE) open. Whether it is MPLAB for Microchip devices or CubeMX for ST microcontrollers, these tools help lay out the pins and show what functions each one can perform. It becomes much easier to translate that into the schematic and route the board efficiently.
Ayrton: So at the same time, you are also thinking about the mechanical side. How big the product will be, where the subsystems need to be placed for mechanical interaction, and even how electrical signals interact within the system. Then you go into the IDE, which is the coding environment that allows you to configure and generate the necessary software settings.
Xarion: There are four key pieces of software we use at Element. First, there is the mechanical side with SOLIDWORKS. That is where we design the enclosure and other physical constraints.
Ayrton: And then we bring that into Altium for PCB design.
Xarion: Yes, SOLIDWORKS handles the CAD, Altium takes care of the PCB layout, and then you have the IDE, which is used for software development.
Ayrton: The IDE is mainly for firmware coding, for Atmel. For microchip microcontrollers, we use MPLAB.
Xarion: Everything is moving towards more universal tools now. Even Visual Studio Code has built-in code generators, which are useful for electronics engineers. It allows them to quickly write test software to verify that the hardware is working before passing it on to the firmware team.
Ayrton: So they can integrate it properly.
Xarion: Exactly. The electronics engineers can go through their checklist and confirm that everything on their side is working as expected before handing it over.
Ayrton: The other essential resource is data sheets. While designing schematics in Altium, we are constantly referring to data sheets from different suppliers. Some are only ten pages long, but for a microcontroller, they can be thousands of pages.
For example, the Atmel M7 high-speed microcontroller we use in many of our designs has a data sheet that is around 3,000 pages long. And I am not exaggerating.
Xarion: Using the IDE is a great shortcut because it saves you from having to go through thousands of pages of data sheets. Those documents contain a huge amount of information, and sometimes they can be difficult to interpret. The IDE simplifies things—it is just a click, and it tells you exactly what each pin can do, making the process much easier.
Ayrton: Exactly. So we use the IDE to configure the different pins. Once we move into the schematic stage and start integrating other components or subsystems, we often run circuit simulations. These days, we seem to rely more on open-source tools for quick checks.
There is an online tool we have been using recently, I cannot remember the name, but it is great for simulating analogue signals and circuits.
Xarion: They are really useful, especially for simple RC circuits, timing analysis, and basic circuit behaviour.
Ayrton: And digital switches as well.
Xarion: Even for filters, you can run a frequency sweep and get a quick response curve. It has become so easy to do now.
Ayrton: Once we have a schematic, we move on to laying out the circuit board. The first step is always placing the critical traces—starting with the antennas.
Xarion: Yes, you need to position everything where it needs to be before you even think about routing traces. If you are working with RF, always start with the antenna. For a PCB antenna, placement is critical. If you are using a UFL connector for an external antenna, you have a bit more flexibility.
You also have to place the connectors first because they are fixed—you cannot just move them later. Once you have the key components and connectors placed, you can start planning the rest.
At this stage, before running any traces, the board looks like a complete mess. It is just a spider’s web of unrouted connections. To someone unfamiliar with PCB design, it looks chaotic. But in your own mind, when you have a clear picture of the final layout, you know exactly how everything will connect.
From there, it becomes a back-and-forth process. You might find that to run a particular trace cleanly, it would be better to swap a pin on the microcontroller. There is always some iteration involved.
Ayrton: Yeah, that is how we approach it. Once the circuit board is built and working, the next step is testing. The main tools we use at this stage include an oscilloscope for probing and measuring signals.
Xarion: These days, because schematics are directly linked to PCB layouts, we rely on oscilloscopes a lot less. Unless you are decoding some obscure protocol or verifying TTL signal levels, there is not as much need for heavy probing.
Ayrton: Yeah, much less of that now.
Xarion: A lot of the time, we are using reference designs and recommended application circuits. The manufacturers provide everything—the exact components, their specifications, and sometimes even the supplier details—so you know it is going to work.
Ayrton: As long as the correct component is placed on the board.
Xarion: Exactly. If something does not work, it is often a mechanical issue rather than an electrical or firmware problem. It could be that one pin on the microprocessor did not get enough solder during assembly. You end up spending an entire day debugging software, only to realise later that the issue was just a dry joint.
Ayrton: That is why having a good microscope is essential.
Xarion: A microscope is actually one of the most useful tools in electronics, and they are so cheap now. Some of the high-resolution models even connect to a screen, which makes inspections so much easier.
Ayrton: I always see the guys at Gary’s workbench using high-powered microscopes. They zoom in, inspect tiny joints, and even solder directly under the microscope.
Xarion: I can’t solder through a microscope.
Ayrton: Neither can I! But some people are incredibly good at it. It is pretty cool to watch. There are so many other electronics tools out there, but overall, I think our toolchain is fairly standard.
Xarion: You also do not want to use every microprocessor out there.
Ayrton: Absolutely.
Xarion: Sticking to an ecosystem is important. You already have the development tools, existing code, and reusable building blocks. Just because a new microprocessor is released does not mean you should jump to it.
Ayrton: I hate that. It is my absolute pet hate when an engineer sees the latest and greatest microcontroller and insists on using it. I just think, No, no, no! Do not touch that! Because switching processors means sinking months of extra work into updating firmware, adapting libraries, and debugging compatibility issues. We have been down that road too many times.
Xarion: Unfortunately, it sometimes comes down to a personal decision. When you have an engineer who is really passionate about using a particular chip, you want to believe in them.
Ayrton: If they take full ownership of getting that chip across the line, then I am all for it.
Xarion: But experience matters, and sometimes experience should take priority.
Ayrton: You would hope so. But at the end of the day, it comes back to the engineering triangle. Time, cost, and quality. If something is amazing but takes a huge amount of extra time, which then increases cost, it may not be the right choice for the business or the project.
However, if that chipset provides a major functional advantage that reduces time elsewhere or enables something entirely new, then it might be worth it.
Xarion: Just make sure you really need it. Do not use it just because it is new.
Ayrton: One of my favourite sayings in electronics, and I do not know if this is actually true, it is just my own hypothesis, is that every chip has a bug. I have come across this multiple times with different microcontrollers and even with sensors like accelerometers.
For example, in the first ShockWiz design, the accelerometer we used had a critical note buried in a 100- or 200-page data sheet. It was a single line that said, If you are depowering this accelerometer, you must take the voltage all the way to zero. Otherwise, when you repower it, it will not wake up.
That was not in an errata sheet, just hidden in the main documentation. We missed that detail and did not include a pull-down resistor on one of the power pins.
Xarion: So the pin still had some voltage on it.
Ayrton: Exactly. If you pulled the battery out of the ShockWiz on the P5 versions and put it back in quickly, within about 30 seconds, the device would not power up again.
That is a classic example of every chip has a bug. The information was there, but someone had to actually notice it, understand the impact, and include the right component in the reference design.
The problem is, for a battery-powered design, a pull-down resistor on the power supply is not ideal because it constantly draws current.
Xarion: It is always consuming power.
Ayrton: That is just one example. Another was my first version of Converged—we called them Converged—which was a highly condensed data logger for mining trucks. I packed everything onto that board. It had a very fast microcontroller, around 200 megahertz, and I used every pin on the BGA package.
The I²C bus on that particular variant had a really strange bug. We could never get the IMU, which was running on I²C, to work properly because it was using the last available pins. I should have used SPI, but I went with I²C instead.
The errata note about this issue was buried deep in an Altium forum somewhere. We spent weeks, maybe months, banging our heads against the wall trying to figure out why it was not working. That is cost and time wasted.
Xarion: Eventually, you just work around it in software because you cannot afford to keep spending time on it.
Ayrton: In this case, we could not. What we eventually discovered was that this particular version of the chip, the U variant or whatever it was, just did not work with I²C. The only solution was to redesign everything around a different variant of the chip.
We ended up doing another board spin, but it was a completely different design because the new chip variant required significant changes. That is why I always say, every chip has a bug. Once you get a chip working with its known issues, it is very hard to justify moving to a new one, because that new one will have its own set of bugs.
Xarion: At least with the one you are using, you are familiar with its quirks.
Ayrton: Exactly. You have already worked around its issues, or you have not discovered them yet. Sticking with an established ecosystem is one of the best ways to develop products quickly, efficiently, and cost-effectively.
I think a lot of young engineers get caught up in the hype. They see the latest and greatest new chip and think, This is the best one out there! But there is a reason why it has not been widely adopted yet.
Xarion: Another challenge is that when engineers run into problems, they turn to online forums for help. But I think manufacturers are missing an opportunity here. They could make a lot of money by offering proper, structured training courses.
If they had a one-week focused training session on a new device, it would save engineers months of trial and error. I think people would sign up in no time.
Ayrton: I think they are starting to do that. Yonathan recently did the Nordic course, and he said it was very good.
Xarion: It is still not that common. Manufacturers assume there is already enough information online for people to figure things out themselves. But we do not have time to sit around waiting for someone on a forum to reply. If we could get into a structured course for a week and go through everything properly, it would save so much time.
Ayrton: There is a real difference between Australia and South Africa when it comes to engineering support. You have worked in both, so you would have seen it firsthand. I have also done a lot of work in the US, and one thing that stands out is how many applications engineers they have.
Even when we were doing projects for American companies while based in Australia, we were able to get strong support from the US teams. The electronics industry is amazing because they plan so far ahead. They are thinking about supporting products that might not even launch for another five years.
But part of that comes with certain agreements and structures. Unfortunately, in Australia, we do a huge amount of engineering, but we have very few applications engineers, which means minimal support. In contrast, working with American companies, we had much more access to help, and the level of support was far deeper.
Xarion: They are very good at selling it.
Ayrton: Absolutely.
Xarion: And that is part of the issue. If you want to sell a product well, you actually need to know it inside and out. You can sell something based on specs, but once you truly understand the pain points your customers are going through, that is when you can really provide value.
Ayrton: It is the same story on the mechanical side with SOLIDWORKS resellers. We are using these tools every single day, constantly problem-solving and pushing through roadblocks.
Xarion: We could sell it better than them because we know every little detail of how it actually works in practice.
Ayrton: And the resellers and support teams often have limited resources. But at the end of the day, we figure things out ourselves and get the job done. By the time we have solved a problem, we probably know as much as—if not more than—the applications engineers providing support.
One challenge I see coming is how forums and online communities are changing. You and I have both contributed to forums over the years, sharing knowledge and helping others. But with ChatGPT and AI tools becoming more common, people are getting instant answers instead of searching through forums or asking for help.
Xarion: That means fewer people are contributing back.
Ayrton: For example, StackExchange traffic has dropped massively. In engineering, if you are benefiting from open-source communities or collaborative spaces, you have a responsibility to give back.
Xarion: Do not just take.
Ayrton: Exactly. Even if you are using ChatGPT or any other AI tools, if you solve a problem, you need to document it. Otherwise, as we move forward, we will not see these challenges anymore. They will just be absorbed into machine learning models, stored inside large language models, and effectively locked away.
It is not about intellectual property—it is about knowledge. I am a mechanical engineer who developed an interest in electronics, and I taught myself largely through the internet. I learned by reading about the challenges other people had posted and how they solved them. If people stop contributing back to these open communities, others like me might not have the same opportunities in the future.
Yes, AI will provide answers, but if we are not actively contributing new knowledge, that information pool is going to stagnate.
Xarion: It comes down to effort. Taking information is easy, but contributing back—helping others by sharing solutions—requires time and effort. You have to walk the walk.
Ayrton: Absolutely. And a lot of engineers tend to be introverted, so many will just take without giving back. That is a big challenge for the community.
We all need to contribute. I have done it at times—I use Reddit a lot, and there are some great high-tech communities on there. I have contributed back, especially in areas like SOLIDWORKS, but probably not as much as I should have.
Right now, I think it is more critical than ever that we continue sharing our learnings online. We need to keep growing the collective knowledge of the internet, rather than allowing it to stagnate and become solely stored in AI models. Just my personal opinion, but I think it is important.
How Can Electronics Design Be Done Quickly?
Ayrton: This is the big challenge. It is something I have been thinking about a lot lately, and I am noticing an undertone of this across different projects we are working on.
Engineering is never finished. Engineers and designers can polish things forever. But the real art is what we keep coming back to, the engineering triangle. It is about delivering an outcome that meets the specifications in the shortest possible time and at the lowest possible cost.
Xarion: You have to draw the line.
Ayrton: In our electronics work, we have been lucky to build up a huge library of knowledge over the years. We have refined different subsystems through multiple iterations.
The first version might have released the smoke. The second and third versions still needed work. But by the fourth version, it was dialled in.
The way we move fast is by reusing those refined building blocks. We take pieces of existing IP and drop them into a new design. We use our toolchain, and because we know it inside out, we can quickly meet the client’s minimum specifications.
Xarion: That is the beauty of experience. You have already solved these problems before. You have proven building blocks, circuits you know work because they have been used in previous products.
This allows you to rapidly build a system for a client. You take a bit from one design, a bit from another, integrate the software that is already developed, make a few tweaks, and quickly get a working solution. That is how you move fast.
Ayrton: Engineers coming into an ecosystem should just use it as it is. Do not try to change things unnecessarily, because you might not fully understand it.
Brownfield projects are always harder than greenfield ones. Greenfield work feels easier because you are learning as you go. But when you step into someone else’s ecosystem, with existing notes and design decisions, it is important to put in the effort to really understand how it works and use what is already there.
In the long run, that will be far more beneficial. If you try to start from scratch every time, you will probably run out of time and money pretty quickly.
How would someone these days, if they were starting from scratch or coming into an existing ecosystem, do it as quickly as possible?
Xarion: There is a lot to learn. First, you need to understand the market. Then, you need to understand the technologies. You also need to know which microprocessor to use and, just as importantly, how long those components will be available for.
Ayrton: That is a big one.
Xarion: That is another thing to keep in mind - the longevity of the components you are using, especially if they are specialised. Manufacturers will eventually release newer, cheaper versions, and then you will be forced to upgrade.
Ayrton: All electronic components have a limited service life or sales life. Most of the components I have seen last around seven to ten years. That latest and greatest microcontroller will likely go through several revisions, fixing internal silicon bugs along the way, but it will only be manufactured for a certain period.
During COVID, we saw a lot of end-of-life components get phased out sooner than expected. We had to redesign multiple projects for customers because their chips went end-of-life.
Xarion: During COVID, it was often faster to do a full redesign than to wait for a chip to be restocked. The design cycles became huge because components simply were not available. The best option was to find something similar and redesign around it, knowing that you could secure a reliable supply of 50,000 units.
Ayrton: That is why, when designing something, you need to consider the whole ecosystem of components. You have to look at what is readily available, what has the best support, and what fits within your long-term supply chain.
In our experience, most of that support comes from forums and online communities.
Xarion: One of the best things about Altium is how well it integrates with online component suppliers. You have Digikey, Mouser, and others all linked directly into the system.
It tells you real-time availability, whether a part is recommended for new designs, and whether it is being phased out. Everything is online now, and that makes component selection much more efficient.
Ayrton: It’s always been online for me, Xarion, but not for you! I only got into it around 2012 to 2014, so you have a few more years on me.
Another big factor is the quality of documentation. Early on, I found myself using a lot of Texas Instruments components, especially for power management, because their online documentation was excellent.
Things change, though. They always do. A lot of electronics companies get bought out by other electronics companies, and that is a massive bugbear.
Xarion: And then they just can the whole product line.
Ayrton: Exactly. They either discontinue it entirely or roll it into their existing lineup, and suddenly all the documentation changes. That is why it is so important to stick with an ecosystem you know and work with suppliers that have reliable component availability and strong support.
Xarion: And the entire ecosystem matters.
Ayrton: Documentation, supply chain, everything.
Xarion: You get used to how things work. When data sheets are always formatted the same way, you can quickly reference what you need because you already know where to look.
Ayrton: That is a big one.
Xarion: Ironically, the fastest way to do something is to take your time. If you rush to get a design finished and send the PCB off for manufacturing, only to have it come back with a mistake, you have just lost two weeks.
Whereas if you had spent an extra day or two making sure everything was right before sending it out, you would have saved time in the long run. You need to waste the time upfront to get it right.
Ayrton: My dad always says, the long way is the easy way. It applies to everything, even working on cars. You might think, If I just squeeze in there with this weird tool, I can get the bolt out quicker. But in reality, it would have been faster to take off the extra part and just do it properly, even if it means re-bleeding the cooling system or something like that.
Xarion: It is the same with releasing products. You need to waste that first month or two.
Ayrton: Invest, not waste!
Xarion: Yes, invest! You are going to frustrate some clients when they say, But you promised this would be ready now!
But rushing a product out too soon just creates more delays in the long run because it has to come back, go through the whole redesign process, and be fixed later. Sometimes you have to push back and say, It is not ready yet, let’s do it properly.That way, you actually use less time overall.
Ayrton: Transparency in communication is probably one of the biggest factors. The way we operate here is 100 percent transparent. If you ask, we will tell you exactly what is going on. We can give you the short version, but if you really want to know the details, we will explain the reasoning behind everything.
That is something we have seen a lot recently with different clients. They go with other suppliers, cut corners, or only spend half the budget, and then end up with nothing. Then we have to come in and pick up the pieces.
The long way is usually the easier way, or at least the better way, for the longevity of the product. Do it properly from the start. But it still has to be done within reason.
Xarion: Yeah, you do not want to take forever or fall into an endless design cycle.
Ayrton: Exactly. The goal is to meet the minimum specifications in the least amount of time and cost, then refine from there. That is the mantra of all good product businesses.
We should be working within the ecosystem we already have, clearly defining the minimum specifications, and getting there as quickly as possible—but with diligence. Then we make a Version 1, see if any smoke comes out, wire mod it if needed to get something at least somewhat usable, and delegate tasks so development can run in parallel.
From there, we move on to Version 2.
Xarion: These days, getting a PCB manufactured is unbelievably fast. They work 24/7.
Ayrton: A lot of it is automated now, right?
Xarion: If you watch some of the videos, it is fascinating to see how PCBs are made. Maybe not for everyone, but the way layers are stacked and how 16-layer boards can all interconnect is mind-boggling.
Ayrton: The precision of micro-drilling, laser drilling, and all the plating processes is incredible.
Xarion: For some people, that is really exciting. For others, not so much!
Ayrton: PCB manufacturing is a hot topic right now. The vast majority of it is done in China, but there is a big push for sovereign capability, especially in the US. They have actually started investing quite a bit—maybe not a huge amount, but more than ever before—to bring PCB manufacturing back onshore.
The same thing is happening with chip manufacturing. But at the end of the day, all those chips still need to be assembled onto a circuit board, and most of those boards are still made in China.
Xarion: Everybody wants to do local manufacturing, but in reality, those components are almost always coming from the same place.
Ayrton: There is no negativity towards that—it is just how the industry has evolved. PCB manufacturing is one of the most commoditised and optimised processes I have seen in the manufacturing world.
You can go online, submit your design, get an instant quote that is hyper-competitive, press a button, enter your credit card details…
Xarion: And that’s the value. The price does not change.
Ayrton: And then, one and a half to two weeks later, whatever they estimate, the boards arrive via DHL, sitting on your table, and it is done. The whole process is automated.
Then, usually in the middle of the night, we get an engineering question, an EQ, sent back from the manufacturer. In the morning, we review it, make a decision, say, Yes, make that change, and it is done.
That is really how all engineering supplier relationships should work. It is difficult to reach that level of efficiency, but I think they have achieved it through commoditisation. They had to bring costs down and develop the ability to manufacture quickly.
Xarion: The sheer scale of production helps them save a lot of costs.
Ayrton: It is pretty impressive, pretty amazing.
Xarion: The rest of the world is playing catch-up.
Ayrton: Yeah, that’s right. We have to. But it is a good thing.
What Are the Main Constraints with Electronics Design?
Ayrton: First and foremost, time is a major factor. If you are constantly reinventing the wheel, using the latest and greatest technology without a real need, or spending unnecessary time on details, that is a poor use of time. And time is cost.
Another big factor is choosing the right component variant within your ecosystem. You need to select parts that do not introduce high costs unnecessarily.
Xarion: And, of course, using the right tools for the job. This ties into everything we have talked about today: knowing your products, understanding your ecosystem, and working with familiar technology.
If you are always starting from scratch, searching for new libraries, testing them, finding gaps in open-source code, then realising it does not work and writing your own from scratch, that is all wasted time. And time is money. So working with the right tools is key.
Ayrton: Within an established ecosystem, cost-effective electronics design usually comes down to non-recurring engineering costs, your upfront development costs.
For long-term production, the biggest cost factor is your bill of materials, the components you choose. Picking the right microcontroller or components within your ecosystem is crucial.
Over-specifying is another common mistake. If your product only needs one percent accuracy, do not design for 0.1 percent accuracy, because that will cost you ten times more for no real benefit.
Xarion: And, of course, design for the application. Do not design for what you are dreaming of, which I sometimes get caught up in!
Ayrton: I think all engineers get caught up in that!
Xarion: You have this idea that it would be really cool if the product could do something extra.
Ayrton: It would be really cool. But that is the bane of engineering, especially for young engineers. They get caught up in thinking, Oh, this is so awesome! If I just add this feature…
But you have to know what the specification is, and you have to know…
Xarion: What problem you are actually solving.
Ayrton: Exactly. You also need to understand the bell curve of end users. If the feature you think is cool benefits 90 percent of users, the centre two standard deviations of the bell curve, then it is worth considering.
But if it only benefits you and one percent of users, it is getting cut.
When refining products, the first step is often to delete features. If removing something eliminates one percent of potential users but significantly improves time, cost, and non-recurring engineering effort, then it has to go.
Xarion: Engineers naturally want to solve 100 percent of the problem. But we have to accept that no device will ever do that. If you solve 80 percent of the problem, you have still solved 80 percent of the problem.
Ayrton: So the key questions are: What is the minimum specification? What are the stretch goals?
This is where product management comes into play. It is a level above pure engineering, but it has to go back and forth with the engineering team. If you give engineers a specification that tries to cover the entire bell curve, the project is going to be long and painful.
Xarion: You are never going to get there.
Ayrton: And someone will keep polishing the product forever. Instead, if you define a minimum set of specifications and keep the engineering team focused on that, you can actually deliver something.
Xarion: Otherwise, they will end up deviating a bit, right?
Ayrton: Exactly. They will get caught up in, Oh, but this is really cool! You need to keep asking, Does it meet the minimum requirements? Does it do what it is supposed to do?
Another factor is technical debt. That is a whole separate discussion, but if we can get a product to market quickly and there is some technical debt, we can assess that and deal with it in Version 2.
Ultimately, cost-effective engineering comes down to limiting the scope. Every engineering task should contribute directly to the final outcome. That outcome has to serve a broad section of the end-user population, not a tiny niche. There are many ways to approach this, and we see it all the time with different customers.
I was talking to a couple of clients recently, and they mentioned young engineers who keep expanding the project scope. And I just thought, He is engineering himself a job.
Xarion: It happens because he is not being properly managed. You do not want to stunt an engineer’s growth, you want to empower their vision. But sometimes, you have to put a lid on it and stay focused on what actually needs to be done.
The cool stuff will happen, but first, let’s get the job finished.
Ayrton: Exactly. Really good engineers, and you can put this on record, are the ones who look ahead and think, This is really cool, and I can see how this could be applied in the future.
The best engineers build a business case for adding a new feature, showing how it will provide a competitive advantage later. But in my experience, that kind of thinking is rare.
A lot of engineers take a hit-or-miss approach. Many do things purely for their own learning or personal interest, rather than focusing on what is best for the product or the company.
Managing engineers is a challenge because they will keep polishing indefinitely unless they are given clear boundaries. You have to provide a proper brief and also understand the work itself.
Xarion: You need to have some technical knowledge in order to manage engineers effectively.
Ayrton: Exactly. We have seen this a lot lately, especially with young engineers coming straight out of university.
If you are trying to manage junior engineers, you need to have a realistic idea of how much effort is required to get from point A to point B. That is where people like us, or other consultants, can really help businesses.
If you give an engineer a certain amount of time, they will use all of it.
Xarion: And if it is a whole team of engineers, it is like herding cats, just trying to keep everyone on track.
Ayrton: That is why setting realistic time expectations is so important.
For example, if I say, I think you can finish this set of schematics in a week, the engineer might say, Oh, that is going to be tight, I am not sure.But I know they can do it in a week. And sure enough, it gets done in exactly a week.
If I tell them, That circuit board should take a week to finish, they might push back and say, It is really complicated. But if I give them two weeks, it will take two weeks.
This is something that has to be managed properly in a team environment. I do not believe that project managers without technical knowledge can truly do a good job for a business.
Because, let’s be honest, engineers will take the piss if they can!
I have sat in agile stand-ups where everyone goes around the room estimating how long a task will take. Someone suggests, Oh, that’s a three-day job. And I am sitting there thinking, That is a half-hour job for me.
Xarion: But you can make that call because you have the experience.
Ayrton: Yeah, so you have to be really careful. Everyone needs to be on the same page. If engineers are aligned with the purpose and the outcome, everything becomes much easier.
The best way I have seen to facilitate that is through demos. When everyone knows what they are working towards, it keeps them focused.
All engineers and designers want to see their work being used. That is what really drives them.
Xarion: It is like leaving a legacy, right?
Ayrton: Absolutely. You are leaving your legacy, it is that sense of achievement.
If you can get everyone aligned by saying, This is the demo, we are going to have MVP1 on this date, and no smoke is going to come out, then it creates accountability.
You have your mechanical team, electronics team, firmware team, software team, app team, whatever it is. Everyone looks at the deadline and says, Oof, that is going to be tough, but I think we can do it together.
That creates camaraderie, it creates a challenge, and it also means that if someone does not deliver, they are letting down the rest of the team.
Xarion: But it is also about monitoring the process. If you see things starting to diverge, you need to adjust the goalposts.
Ayrton: Yep, absolutely.
Xarion: You do not want to push someone to hit an exact deadline no matter what, but you need to have a good estimate of what is achievable and allow some tolerance.
Ayrton: The other side of it is technical debt. If people are working efficiently and getting things done faster, that is great. It means they have time to go back and fix any technical debt they have built up.
But if they are rushing too much, they will incur technical debt. They might deliver something on time, but then realise, Okay, in the next sprint or the next phase, I have to go back and fix that issue before it causes bigger problems.
In general, the most successful product development projects I have been part of have had negotiated timelines, with all stakeholders involved.
Xarion: And those timelines are tracked.
Ayrton: Exactly, they are tracked properly. For example, we might say, We are going to have P5 prototypes ready on this date, and those P5s are going to test customers. Or, We are going to have P4 on this date.
At the start, it is hard to fully understand the engineering effort required. So we ask, Do we think this is achievable? Based on our experience, we make a call on whether the timeline is realistic. As the project progresses, we keep checking in. The project management system shows progress, green, green, green, until suddenly, it goes orange.
Now we adjust the goalposts, but with real reasons behind it. Not just because someone got lost in their own world doing cool stuff that was not needed.
You need clear goalposts, set time limits, collaboration across all teams, and good management. That is what makes a project successful.
Xarion: I was about to say, you cannot just give engineers a deadline and expect them to meet it without guidance. Some people might manage on their own, but when you are working in a team, you have to guide them.
Ayrton: Yeah, everyone needs to be supported and feel like they are part of the process.
Cranio
We are currently developing our own data logging and control system, Cranio, to make it cheaper and easier for people to build their own IoT solutions. This involved designing and manufacturing the Pro-IO line of modular electronic devices. What was it like working on this project?
Xarion: This was actually the first project I was thrown into when I joined. It was really interesting because I had started with basic electronics and then transitioned into more advanced embedded systems.
It is incredible to see how an idea can be driven forward and turned into reality. This is exactly the kind of field I am passionate about: getting different systems talking to each other, enabling high-speed communication, connecting to the internet, and displaying data on a dashboard. It felt like a very familiar space for me, so it was exciting to be involved.
The team did an amazing job. There were multiple modules that all had to interface, mechanically and electrically. We had to coordinate between the firmware engineers and hardware engineers, making sure the hardware was fully functional before it went to firmware development. That way, we avoided a lot of back-and-forth issues and saved time.
The whole process went really smoothly. Cranio has been around for a while now, and it has a strong foundation to grow from. The core product is stable, with solid web and app interaction. It is a really impressive system.
Ayrton: I have always wanted to create easy IoT, a system where you can sense anything and automate everything. I found it difficult in the past because existing platforms like Arduino and Raspberry Pi still require a lot of electronics knowledge. You need to be an electronics engineer, at least to some extent, to put together a proper circuit board.
You can buy modules from Adafruit, which is great, but you still need to understand the underlying electronics. Then you have to write firmware in C, which can be challenging. Arduino makes that easier, but even then, you still need to figure out how to interface with your system.
You could use LEDs for simple feedback, but for real applications, a phone app or web interface is a much better solution. That means you need at least three engineers—a mechanical engineer, an electronics engineer (who may also handle firmware), and a software engineer to build the app.
For years, it has been a personal challenge of mine to create a system where we can rapidly develop an electronics widget that is robust and reliable. It should be able to work with any sensor, any industrial interface, and any actuator, without needing a team of engineers to put it all together.
Xarion: A true consumer product, not an engineering product. You should be able to buy it off the shelf, plug it in, and it just works. It should be an easy, seamless process to get the device online and logging data.
Ayrton: But that has been a massive challenge. I started working with electronics back in 2012, and I was deeply involved in it for about four or five years. A lot of the lessons we learned back then became the foundation for Cranio.
Sam was the one who, in 2018, said, Can we stop working on three different projects at the same time, each with its own separate codebase?
Xarion: And there was a lot of overlap, right?
Ayrton: Yeah, absolutely. All of those projects were trying to do similar things. One was integrating with an app, another was sending data to a backend and dashboard, and the third was just an electronics widget. So the big question was, Why can’t we do this in a more consistent way? That has been the main challenge.
For us, the key to Cranio has been making it able to interface with any sensor. And we have now covered them all, in the same way that PLCs interface with various systems. We looked at how PLCs work, how they interact with different inputs, and we went through all the necessary engineering to support 4–20mA, 0–5V, and 0–10V signals.
Xarion: You have stepper drivers, motor controllers, basically anything you can think of can be plugged into Cranio. It will take in the data, process it, and display it on a dashboard. Whether it is communicating over LoRa, Bluetooth, or LTE, you can choose the technology that suits your needs.
Ayrton: When you came into the project, we had already gone through a lot of those early challenges. The core of it all is the microcontroller selection, figuring out which microcontrollers we prefer to work with and standardising around an ecosystem.
Once we had that locked in, we built the core firmware and system interactions. From there, we developed different analogue front ends, digital front ends, and power management solutions.
Power management was a major challenge, especially during COVID. My love of Texas Instruments disappeared overnight when all the components I was using became unavailable. I think the main reason was that those components were being heavily used in the automotive industry. And the car manufacturers basically said, We cannot stop producing cars, so they bought up all the stock.
Xarion: And if a supplier says no to the automotive industry, you know it is because they simply cannot manufacture enough.
Ayrton: Exactly. That forced us to redesign all of our power management systems. A lot of our newer power solutions now come from specialised suppliers. There has been so much iteration and refinement in all of these subsystems that we now have a massive library of proven designs. So when we need to develop a new circuit board to fit a specific form factor, we do not have to start from scratch.
The Cranio form factor itself was designed to eliminate the need for weatherproof cabinets. Instead of using bulky enclosures with cable glands, we use compact designs with silicone seals and cable wedges.
That idea actually came to me while riding my bike, just one of those moments of inspiration. Now that we have a defined form factor, we can simply drop in whatever subsystems we need. We are reusing what we have already built, iterating on it, and extending it. And I think you have seen the results of that approach.
Xarion: But also, we are managing the entire product from the mechanical side as well. We even CNC the enclosures here. It is a one-stop shop for everything, so you know it is going to be a good product.
Ayrton: Yeah, we hope so!
But this is different from the usual approach. And again, this ties back to my core purpose. I have always been the kind of engineer who not only designs the product but also helps implement it on the production line. I have done that in China, a lot in the US, and now quite a bit in Taiwan as well.
But my real passion is this question: Why can’t we do it here? Take Taiwan, for example. They have a relatively high cost of living—possibly even higher than ours in some areas. So why can’t we manufacture at scale in Australia?
Bringing things in-house allows us to do a few key things. First, it gives us the ability to turn around prototype designs faster than anywhere else in the world.
Second, it allows us to learn the manufacturing processes firsthand. As an engineering company, understanding those processes means we can design better products that align with manufacturing constraints.
And third, it lets us actually use our machines to manufacture products.
We will see where this takes us, but for now, we know that Cranio Pro-IO is moving forward. We already have some trial deployments happening. Because of how we have structured the ecosystem, we can pivot quickly within the same form factor. We can take that circuit board and drop in different subsystems as needed. If a specific sensing module is required, we can build it and integrate it seamlessly, while keeping everything speaking the same language throughout the ecosystem.
Xarion: It is future-proof. If a new type of sensor comes out, you can just build it into the system, add it to the stack, and it works straight away.
Ayrton: Another big thing we are seeing now—and I was just discussing this with a colleague this week—is automation. AI is incredible right now, and there is a huge wave of new applications where people are implementing AI models. But the challenge is still the interface to the physical world.
Fifteen years ago, I was struggling to get basic sensor data and having to mess around in Arduino just to make things work. And, honestly, that is still a challenge today. In some ways, it is even more of a challenge now, because while we have made massive strides in software, we still do not have an easy, reliable way to robustly interface AI-driven applications with the physical world.
That is where we fit in. If we can be the provider of modular hardware that follows a standardised way of doing things, speaks the same language across all modules, and exposes clean interfaces to the controller, then we are offering something valuable. We can provide a reliable, easy-to-integrate hardware solution as a widget-based system that just works.
I’m really glad you had a good experience with the Pro-IO!
Ayrton: We work closely between Altium and SOLIDWORKS. One of the things that has really sped up our process is that we start with a mechanical design that we believe will provide the best user experience. From there, we define the circuit board shape and hand it over to the electronics team.
Xarion: The speed between electronics and mechanical design is incredible because they are now fully integrated.
Ayrton: Absolutely.
Xarion: It makes everything so much easier. I remember when we were working on the GPS puck redesign, it was incredibly fast. We got the PCB layout done, talked to the mechanical team, and if we needed to adjust anything, they would tweak it and push it back to Altium. The electronic engineers would then see the updated space, make the necessary changes, and place a new connector. If we needed to shift a component slightly because something was in the way, we could make those adjustments in just a few days, all because everything was in one place.
Ayrton: The biggest game-changer for me has been the Altium-SOLIDWORKS integration, specifically CoDesigner.
Back in 2014, I had to manually bring in STEP files to keep things in sync. The workflow required designing the mechanical model in SOLIDWORKS, defining the circuit board shape, importing that shape into Altium, laying out the components, exporting the PCB as a STEP file, and then bringing that file back into SOLIDWORKS for fit checks. It was not a long process, but it involved a lot of back and forth. Now, CoDesigner has made it seamless.
The next level of integration allows changes in either software to reflect live in the other. Now, we can define the board shape in SOLIDWORKS, send it to Altium, and start placing components. When we push the updates back, those components appear directly in SOLIDWORKS as native models. Even better, if you move a component in SOLIDWORKS, it automatically updates in Altium. No more exporting STEP files, no more revision mismatches, no more back-and-forth headaches.
There was a time when the system was broken. About a year ago, it just did not work properly, so we had to go back to STEP files. But in the latest versions, it has come ahead in leaps and bounds. That toolchain has been a massive boost to our efficiency.
Xarion: It saves so much time. Before, you would manufacture a PCB, put it in the enclosure, and then realise a capacitor was touching the edge. That meant going back to redesign, making changes, and rebuilding.
Ayrton: But now we have Altium's 3D interaction.
Xarion: Exactly. We looked at this earlier, but it is worth mentioning again. With this system, everything is included—the enclosure, the component heights, and exact STEP files for each part. You know before manufacturing that everything will fit perfectly. If you design everything correctly, you cannot go wrong. You get it right the first time.
Ayrton: Those components, like the USB-C port and the SD card slot, have to be positioned with precision, within 0.1 or 0.2 millimetres. If they are even slightly off, the silicone flap will not seal properly.
Xarion: Exactly, because this is an IP-rated product.
Ayrton: That is crucial, especially for a consumer product that needs to function in real-world environments. Consumers are the hardest users to satisfy because they will push a product to its absolute limits. Not only will they abuse it, but they will also demand the lowest possible cost while expecting the best user experience.
Xarion: So you have to get it right, and you need to do it with as few iterations as possible.
Ayrton: This is the full stack-up model. This is the module we were talking about earlier. The entire model includes all the different parts, but the circuit board itself comes in as a sub-assembly.
SOLIDWORKS and Altium have an interconnect feature, which I do not have set up here, but it allows SOLIDWORKS to generate the circuit board using native elements. It builds the PCB and then creates each individual component using extrude features and similar modelling tools.
I think it also imports STEP files, so for things like connectors and headers, you get accurate models where you can see exactly how things make contact.
Xarion: Even down to the label.
Ayrton: Yeah, so it actually builds everything directly in SOLIDWORKS. Once you have brought the model in from Altium, you can move components around, left, right, wherever you need them, and then use the Altium interconnect to push those updates back.
We have done that before, right from the start with these Pro-IO stacking modules. It is pretty seamless now, and it makes a lot of sense to work this way. When the integration is broken, though, it is a real pain. And for a while, it was broken.
Xarion: When you depend on it, that becomes a big problem.
Ayrton: Yeah, but you can always go back to STEP files if needed.
I started off using Eagle, back when it was truly open-source. But that changed, and I switched to Altium pretty early on. Now we have three perpetual Altium licenses, and they are always booked out by the team, always in use. It works really well with SOLIDWORKS, though obviously, there are plenty of other PCB design programs out there.
I really like the idea of KiCad and open-source engineering tools in general. The great thing about open-source tools is that they are always evolving and improving.
Xarion: They also make it easier for beginners to get started. Since KiCad is free, more people use it, which means more people ask questions, contribute answers, and develop add-ons. There are so many extra tools built on top of KiCad now.
I found a tool that lets you create a PCB in KiCad, and it automatically generates an enclosure with bushings and everything. You just 3D print it, and you are done.
Ayrton: Open-source engineering is the democratisation of engineering. It levels the playing field. We pay for Altium, and it is actually not that expensive compared to other industry-standard tools. When I first looked into it, Altium was nearly an order of magnitude cheaper than some of the alternatives.
Xarion: It has become the standard, I think.
Ayrton: It really has. And I think that is because it is feature-rich, it improves every year, and the bugs actually get fixed. It is just a great tool to work with. But if you cannot afford it, there are still free options. I think Altium has a free version, CircuitMaker. And then there is KiCad, which is a fantastic tool for getting into electronics.
Electronics should not be intimidating. For me, as a mechanical engineer, it is a bit scary, because you cannot see it. You cannot physically touch or feel what is happening. But once you have the right oscilloscope and have worked with enough different modules to understand what is going on, it all starts to make sense.
Xarion: If you look at a PCB and actually understand that every component on there has a function, it becomes much easier to follow what is happening. If you are just looking at a board without context, you only see a bunch of components. But once you drill down into the details, you can start recognising patterns. As engineers, we can tell just by the layout what different sections are doing. You can look at a board and say, Oh, this is definitely a power supply, there is some filtering here, and this part is a matching circuit.
Ayrton: Were you one of those kids who annoyed their parents by pulling everything apart?
Xarion: My mum always used to joke that for my 10th or 12th birthday, my dad bought me an old-school TV or a tape recorder just so I could take it apart. I would pull out all the screws and open it up, and back then, everything was mechanical. It was not all done electronically like today. You had pulleys and little chains controlling timing instead of software.
Thinking back on my journey, a lot of it came through my dad’s influence. I only wish more kids could experience that kind of hands-on learning today. But now, people are starting at a completely different level. They do not always understand where things come from. Even from a software perspective, people are writing in high-level languages without really knowing what is happening underneath in the microcontroller.
You only gain that deeper understanding if you have worked with low-level programming, like assembly language. But that is becoming rare now.
Ayrton: I think it can still happen, but it has to be an active learning experience. My journey was different. I started at a high level, working with off-the-shelf electronics kits.
Xarion: We have come at it from opposite ends and met in the middle!
Ayrton: Exactly. I stepped away from low-level electronics for a while, but I started with the little Dick Smith Electronics kits, like a lot of people did.
At university, I was fairly good at the electronics-related subjects. I started at the Arduino level, and as we needed more functionality, we kept running into Arduino’s limitations. That led us to MPLAB and Atmel Studio. Then we found those limitations and eventually moved on to designing our own systems. Along the way, I brought in people like Sam, who could handle the more complex parts of the process.
For me, learning electronics was always about necessity. I had a problem to solve, and I needed to make specific electronics modules work within a particular mechanical system. That often meant banging my head against the wall until I figured it out. I have worked my way down to a certain level of understanding, but I do not have absolute first-principles knowledge of everything.
As engineers, there is always a balancing act. Do you need to understand everything at the lowest level, or is it enough to just take things as they are and use them effectively?
Xarion: You started at a higher level and worked your way down.
Ayrton: Yes, but I still believe there is always a benefit in understanding things at the lowest level possible. To be a true expert in any engineering field, I think you have to do that.
But at the same time, it can also be a bit of a trap. If you get too specialised, you risk limiting yourself. I have seen a lot of software engineers jump between different areas, all working with high-level languages. They will say, I have done front-end, I have done back-end, and now I want to do firmware.
And I always wonder, Have you really done front-end? Have you really done back-end? Did you actually contribute to the React libraries, or did you just use them?
Xarion: Or did you just copy from Stack Exchange?
Ayrton: Anyone who is going to be a lifelong contributor to engineering is someone who has gone deep into first principles and then started to build on that knowledge. My personal opinion is that every engineer, at some point in their career, should become a domain expert in at least one area.
Xarion: You cannot be an expert in everything.
Ayrton: No, but you should be really good at one thing. You should either be state-of-the-art in that domain or actively pushing the state of the art forward. Once you reach that level, then you should expand into the surrounding domains that you interface with. That way, you can not only improve your own work but also contribute valuable insights back to the field.
Xarion: And you should never assume that you know everything. You might be working on a project, and a junior engineer will mention something that makes you stop and think. Never assume that just because you are more experienced, you know it all.
Ayrton: That is the beauty of engineering. You are always learning, and hopefully, you are learning from the people around you. If you are not learning from your peers, then maybe you are not in the right environment.
Cranio has been a long process, and there is still a lot of work ahead. But the Cranio Pro ecosystem is now well established, and we can develop new solutions very quickly. If we need to interface with a new sensor or actuator, or develop a new subsystem, we no longer need to build messy Franken-modules.
Xarion: These days, it is really easy, and there is very little that can go wrong. If the schematic has been done properly, if the components match up, and if everything follows the correct design process, then the result should be solid.
Ayrton: Especially if you use the reference design.
Xarion: Exactly. If you use the reference design and follow all the steps we have refined over time, there is not much that should go wrong. When you apply power, there should be no smoke. Unless, of course, something mechanical is wrong, like a blob of solder shorting a connection, a component placed the wrong way around, or someone accidentally rotating the microcontroller. But at this point, there should not be too much smoke coming out of our boards.
Ayrton: We will see!
It will be great to finally get this thing to market. But I think there are also opportunities in the middle—ways we can leverage our IP library. We should be making it easier for people to approach us and say, Hey, you already have a closed-loop motor driver system, and I have these industrial sensors. Can we just…
Xarion: That’s all just building blocks!
Ayrton: Exactly. Drop it onto a board, put it in a Deutsch box, or mount it onto a circuit board inside a cabinet, and bang, we are done.
The Engineering Triangle is a podcast about how to design & produce the best smart machines and IoT, as fast as possible, at the right cost.
Host, engineer, and Element Engineering Australia managing director Ayrton Sue explores key engineering and manufacturing domains – mechanical, electronics, firmware, native apps, web software, UI/UX, and more – to discuss the best (and worst!) practices for developing industrial & consumer digital solutions.
Subscribe for more!
Comentários