 Talktoday is just going to be on Building Cantac Pro, which is the newest version of this tool. Just feel the process that I end up going through to make it from an idea into a real thing. So talk a little bit about the design and just some of the logistics of actually building hardware and getting it out to the market. Hopefully, if there are people out there that are interested in doing this sort of thing, it's a way that we get some ideas, but the tricks and challenges of building your own hardware tool. So we're going to run along here. What is CAN? So this tool is called Cantac Pro. It is a CAN to USB device, but I'm quickly going to talk about CAN for those that are not familiar with it. Stands for Controller Area Network, and it's just a networking technology. It's a bus, uses two wires, differential signaling, and it's used to send, I'd say, medium speed messaging around real-time systems mostly. So it's the most common network that you'll find in CARs today. There are some new network technologies that are coming out and starting to be integrated into CARs more and more, but CAN is still sort of the de facto standard, the most common thing out there. It's also found in a few other places. So you'll find it in SCADA systems, industrial control systems. There's actually a certain amount of use in things like avionics systems for sending messages back and forth between avionics components. There's a lot of motor control that is done over CAN, so from small to very large motor controllers where that's the communication interface that's used. Those are the most common places that you'll see it. There's a few more that come up. It's a multi-master bus, and what this means is that every node on the bus can act as a master. So in other words, if you connect onto this bus, you have the ability to send messages without anyone asking you to. You can just broadcast messages out to everybody. But there's also a priority and an arbitration scheme, which is pretty cool. So messages that have higher identifiers actually have lower priority, and that's enforced by hardware. As long as all the hardware is actually compliant, this allows you to do real-time messaging with priorities, which can be quite useful when you have some messages that are just more important for safety reasons than others. There's also CRCs or cyclic redundancy checks at the hardware level, so there's mapping to make sure that the data that is delivered is actually the same as the data that was sent. However, there's been a bunch of interesting security things to come out of CAN in the last couple of years. The main reason for that is simply that every single message on the CAN bus tends to be trusted in the way these systems are deployed today. Historically, that's because in old-fashioned CAN, we'll say, the normal CAN 2.0, the messages are only eight bytes long. There's not a lot of room to do any crypto or anything like that. And also, the controllers that receive the send and receive these messages are usually fairly limited embedded systems that don't necessarily have the resources to do a lot of pedagogy and a lot of the signals are real-time, so you need to be able to take that torque request to a motor and deliver it immediately, not after it's been decrypted. With newer hardware and newer techniques, there is some ability to do more signing and encryption on the CAN bus itself, but a lot of the systems out there, every message you send it, it's trusted. There's also some higher-level protocols of interest on CAN, so there's CANTP and ISOTP. And I said that those normal CAN frames are eight bytes long, and that allows you to chain a bunch together to get 4,095 bytes, up to 4,095 bytes. And then based on top of that, you have something like Unified Diagnostic Services, which is an actual application protocol for doing diagnostics with your car. Whenever a mechanic plugs a scan tool into your vehicle, they are likely using some stuff from UDS, Unified Diagnostic Services. There's also CAN Open. CAN Open is a protocol used a lot in motor control, and CCP and XCP, these are CAN calibration and X-meaning, anything calibration protocol. And these are used, the proprietary protocols that are used for mostly debugging, but sometimes they get left enabled on controllers and you can use them to do bad things. So yeah, there's a lot of interesting stuff on CAN, but it's just another network. The problem is, well, you need hardware to talk to it. And you need a device specifically that's going to plug into your computer and also to the CAN bus. And at a time back in 2014-ish, whenever I built the original CANTACT, there wasn't much out there to do this. That was at a reasonable price. You could go to a company like Vector and spend five figures on a very fancy setup that most of the actual OEMs that build cars, like GM, Ford, Chrysler, those types of companies, that's who they're buying their tools from. It's way outside the reach of the hobbyists, though. You don't have sort of the mid-tier, which is less expensive, but still not as significant, things like intrepid control systems, where yeah, the hardware might be pretty cheap, a couple hundred bucks, but their software is still low thousands. And then there was a few open-source projects, but none of them you could actually buy. So there were a few designs out there, but there was nothing that was actually available for purchase. So I decided, hey, this seems like a thing that we need, a cheap USB to CAN tool. So I designed this guy, the original CANTACT. And originally, I did it by, while building a board with this ST microcontroller. It's the STM32F0 series, so Cortex-M0, very low-cost microcontroller. It was one of the cheapest microcontrollers I could find that had both CAN and a USB peripheral. And so it won. And yeah, it's a pretty simple board. It's, you know, you got the microcontroller up here, you got your CAN transceiver, which actually does the conversion electrically. Hey, you got a crystal to run the microcontroller at the right frequency, which turned out you don't actually need, because there's a cool feature that will let you just do clocking over USB. And then yeah, it's got a connector on the end, and this is a fairly standard connector, and you can select some of the pinups. Originally, this used something called SL-CAN, or Serial Line CAN. And that does CAN over a virtual serial port or a virtual COM port. It's really slow, and you don't want to use it. So thankfully, this guy, Hubert Dekmeier, wrote this firmware called Candlelight. And that actually targeted the existing GS-USB driver on Linux. This was from another company. It was an open-source driver, and it was already in mainline Linux. So once he wrote that firmware, you could reflash this device over USB, load his driver on, and then you just plug it into any Linux system, and it becomes a CAN network interface. But it had its limitations. There was no isolation, so the voltages here on the CAN port could theoretically get to your computer, which could be bad. It's a single channel, only one CAN channel, but it was cheap. It was there like 50 bucks or something, and it actually got cloned and forked a bunch. There was the cannibal, the candlelight, the Vulcan, and a bunch more. A lot of those actually improved on this design in various ways, and it was actually really cool to see see did people take your design and make something new out of it. So whenever I went to the CANTAC Pro, I had some goals. The first one was we wanted two channels because most microcontrollers had it, and why not? High-speed USB, so because I wanted to target CAN FD, the newer, faster CAN, I needed a higher throughput. So the standard USB wasn't good enough. We needed at least high-speed. CAN FD support, and this is a newer flavor of CAN that allows messages of up to 64 bytes, whole 64 bytes of payload, but also allows variable rates between the data rate and the arbitration. Basically what that means is you can put a lot more data on the bus. There's a lot more, or you just put a lot more because you can bump the bit rates up for the data phase well above a mega-hurt, which was the limitation on the original CAN. I also wanted to add single-wire CAN support for the few people doing weird stuff with GM vehicles that still use that. I wanted electrical isolation between CAN and USB just so you don't blow your computer up. It's a nice feature. And finally, I wanted to put it in a case because the CAN tax, honestly, I broke a bunch of them because it was just a board. It was cheap, but it was just a board, and if you stood on it, it would break. So I wanted to put it in a box. The first step here was to figure out how to get CAN FD and single-wire CAN, and the real key was choosing the right microcontroller. I looked around at everything that was out of the time and I settled on this LPC-54616J51TEL BD-DAL, and that long part name or whatever. It's a NXP LPC chip. It's a Cortex-M4, ARM Cortex-M4. But it was great because it had high-speed USB to CAN FD and it had a ROM-based USB boot loader. So you can actually hold a button down or short a pin out while you connect power and it will jump to a boot loader. This is perfect because it means, one, I don't need to write a boot loader. And two, if you break your device somehow and you don't have the JTAG stuff to program it, you can actually just do it over USB because it's built into ROM and you can't overwrite it. So it's really nice for that. There was also this development board available which was basically my product. So this board on the right here is the board you could buy from NXP and it had that chip as well as this dual CAN FD thing that you could slot on top of it. It was like 200 bucks and it was everything I needed and more. So I also had to choose the CAN FD transceivers. I ended up with this MCP25612FD which is from Microchip and it's just a dual CAN FD transceiver. And then for single wire CAN, I ended up using two dual pole single throw analog switches just to switch the CAN signals between the high speed or the CAN FD transceiver and the single wire transceiver. And then I used this NCD73561 from ON Semiconductors, ON Semiconductors and that's a single wire CAN transceiver. So quickly just to talk about the isolation. The idea here is, you know, you're plugging your CAN tool into some system. Maybe it's a high voltage system that could have a high voltage on the CAN line when it was wired incorrectly or maybe it's a system that could have some very large transients show up. Now you can have input protection but that'll only go so far. Usually if you have a real big voltage on that something could happen where it reaches your computer's USB port. And you know, not ideal would be blowing up your $150 CAN tool. Really bad would be blowing up your $1,500 laptop, right? We'd rather blow up the cheap thing and save your expensive laptop if at all possible. So there are isolated CAN transceivers out there that will actually do all this for you. The problem with them is none of them will really do CAN FD and single wire. And also they still require you to have a separate power supply that's isolated. So I ended up going with a solution that was maybe a little overbuilt but it worked. I used the Silicon Labs SI 866 series of chips to do the isolation of high speed signals. These things will handle 150 megabits per second which is more than enough for CAN FD. And they also provide five kilovolts of isolation. So, you know, a lot, a lot of isolation there. I don't guarantee that a device to be rated to any particular isolation figure but that chip is rated to that number. The way that these work is really cool as well. It's shown over in this little block diagram. We put a signal in and they actually have a RF modulator and there's an isolation barrier and it's RF over that barrier and then it's picked up by a V modulator and then put out in the pan on the other side. So as a result, there's no electrical connection here. It's an RF connection but it's an RF connection inside the piece of silicon which is really cool. Now for other signals that I needed just to switch between single wire CAN and high speed CAN, move stuff around, set some of the mode pins on the transceiver. I just went with an optocoupler because those are these GPIO signals and they're really slow. They're either on or off. They don't switch on or off quickly. So for that use an optocoupler, it's a really cheap part. The problem is it's about a thousand times slower than the silicon labs chips. That's why we couldn't use it for everything. You know, these optocouplers, they work. They're great for low cost isolation. You can get them in really high ratings for isolation and everything but they tend to be slow because the way that they work at a very basic level of understanding at least what I have is you put your input signal on one side, turns on a little LED and then on the other side of that isolation barrier there's a photosensitive transistor that if it sees that light it'll essentially close the switch. So it allows you to isolate across the barrier with light instead of RF in the case of the silicon labs chip. And again, these are slow but they're cheap. You also need to have a power supply that's isolated so you have five volts coming off the bus of your USB port on your computer. That's nice. But we need to provide an isolated five volts that if there's a big transient there still is protected. For that I use this Recom five volt isolated DC-DC module. It's like an all-in-one part. You just slap that down with two big pastures on it and it takes care of the rest, which is great because designing those fancy power converters is not the easiest thing. The only bad news is this is actually the least reliable part I found in the design. I had about from 250 boards in the initial run I had about four of them fail and all of them except one were due to this part. The last one was actually interesting. It was due to one of the connectors was incorrectly built. I had never seen that before but there was three out of 200 and something that this part was failed. Anytime you're building hardware and any number you're going to get failures it's just part of life. And it's not clear whether my manufacturer ended up breaking these due to the way that they were assembling or whether they came built or broken. So I can't really blame Recom without doing more analysis. But that was actually one of the most commonly failed parts but it wasn't that big of a deal. The enclosure. So putting things in boxes sounds like it should be easy but it's actually really hard. You have a few options right when you're trying to build an enclosure. The sort of most obvious one in the maker world is well 3D printer. Everyone's got a 3D printer now or knows someone who's 3D printer they can use. I highly recommend that you just know somebody who's 3D printer you can use because you will spend more time playing with your 3D printer than you will printing anything. But if you got someone whose hobby is making a 3D printer work you want that person as a friend because they'll do nice prints for you. That being said 3D printing on mass not really a great strategy. You know it's slow it's not particularly cheap. The parts come out with a lot of variability unless you have a really nice setup it's probably not going to work that well. Injection molding is the way you build parts in large quantity in plastic. The problem is it's expensive. It's mostly expensive in the startup fees getting your molds designed manufactured and you know actually in a fabrication run that could cost you thousands and thousands of dollars. But every once you have that every part costs a few cents right. It's really cheap to stamp them out once you have those molds ready. The problem is I'm not a mechanical engineer. I am really bad at mechanical CAD. I only do the CAD stuff and I knew that I wasn't going to be designing mold. I know nothing about designing molds or anything like that. But I do know a few from school so that's good. What I ended up doing that was going with a company called Polycase which is based in the US and they make you a prefab case so they injection mold their case but they will custom machine holes in it for you. They'll actually custom printing as well if you want. And what ends up happening here is you pay a much lower startup cost. I think their minimum order was about 100 bucks just for the setup of their tooling. But once you pay that cost it's done and then you pay more per unit is the problem. So it all comes out to how many units are you building. If you know you're going to build 100,000 units it's worth going with injection molding. If you think you might only build 10 it's not. So Polycase is a pretty nice in between where it's not super expensive per case and there are pretty good volume discounts but you can also get your first case relatively cheap or your first five cases relatively cheap. So one note and one big thing if you're designing hardware is you need to design your PCB to fit in the case. If you design your PCB and later go okay now let's put it in the case you will regret your decision because it won't just fit and you'll suddenly realize oh well these standoffs they need to be right on the this location on the on the board these holes and you'll go oh I can reroute the board but it ends up being like almost redesigning the PCB every time. So my advice is if you know that you want to have a case for your product from the beginning design it as if it's going to be in the case right from the beginning it will save you so many headaches down the road. So I you know chose this case I bought a few of them that were unmodified and I actually just cut them with a dremel to sort of mock up what I wanted. And then I designed the PCB to match and put it in with the screws and it all worked great. And then I called up a friend of mine who does actual CAD stuff all day and said hey how much will it cost for you to take this model of the case that they give you from Polycase and put the correct holes in it. And you know I paid him for a few hours of work he did that for me and I sent it off and it worked the first time which is great because if I had done that design it definitely would not have worked the first time. So hardware is cool but the problem is that you know software tends to be the limiting factor or the hard part. So when we're talking about CAD there's a lot of different software out there that you could use and you know there's a few different things that I targeted and time dependent will show some demos. But so the software side on Linux the main thing and kind of the best supported best built thing is called socket cam is part of the Linux kernel and if you're on Linux right now this is on your computer probably unless you have an ancient, ancient kernel. Basically these can devices become network devices just like your ethernet card or your Wi-Fi card or whatever and you can literally do you know sudo ifconfig can zero up once you plug the device in and it will bring that device up. You also set the bit rate but you know you interact with it the exact same way that you would with any other network device and there's many tools out there that exist. Canutils is a package that's on most major operating systems that gives you basic you know send cam frames dump cam frames things of that nature. Wireshark actually supports can at least on Linux so you can actually take Wireshark fire it up say dump can zero and it will provide a full dump can and it can do decoded certain protocols as well and there's a bunch more. So to do this I targeted that same GS USB driver partially because I knew it pretty well already and partially because it's already in the kernel and that's really nice because if you buy one of these I don't want you to have to build a kernel module and you know install it because that's just a pain I want if at all Polygon play support right plug a thing in and it just works. That's the goal and for normal can not can FD that's the case. However unfortunately that driver does not support can FD so I need to customize the driver for that and that's still something that you have to build if you want what can FD support. So just to show here socket can kind of sits in this middleware between you know your hardware to the very bottom that's the can controller that's the can tech device. It sits in the network device driver and sort of the protocol family. So if you've used Linux to write socket stuff before you probably have had like a P F for protocol family like P F I P V four V six. There's also a P F can and it works much the same way as a normal socket would and then you interact with it just as a socket would like any other socket. And then at the very top you have your actual application which could be the can you tails or wire shark or something you write. So the thing about socket can is this Linux only it's lovely but it's Linux only and realistically you know cross platform support is something that's that would be nice. Yeah you can run a VM it's okay but having Mac windows and Linux support would be really cool. And so to do this you would normally need a driver for every platform you would need well okay fine Linux is done you have GS USB but you would need to write yourself a Windows driver and a Mac OS. I don't even know I've never bothered writing hardware support for it at a kernel level but I'd imagine you have to write something there as well and that would be a lot of work. Fortunately there's a few shortcuts that I could take here and I got really lucky and they all worked out. So the first one was to use LibUSB. LibUSB is a library that allows you to do user space USB drivers. So it's not a kernel driver but it connects to parts of the of the kernel be that on Windows Mac OS or Linux in order to actually speak to the USB device. The other thing here was Rust. So you know I've written a lot of C in my life and some C++ and I've been playing more and more with Rust. One of the challenges with writing this type of code tends to be writing across platform compliant. Writing across platform C code is really no fun because there's different keyword declarations that you have to make to export DLLs for different platforms and it's a mess. Then you also have to compile on every platform or figure out cross-compiling which is no fun. So Rust actually solved all these problems much to my amazement and made Rust absolutely worth it for this project for that reason alone. It's one code base so it's there's no poundifying you know if Windows if Mac OS it's just one set of code and on Windows Mac OS and Linux you should be able to type cargo install contact if you have Rust installed and it will download and build it for your platform. And I am still amazed that that works just because cross-platform stuff especially at this layer is usually a pain. So I think Rust is a very interesting solution for these types of tools. So the LibUSB has a synchronous and an asynchronous mode. Synchronous is sort of a polling so you ask for the device for data and if it has them it sends it back. That's too slow. There's just too much latency in trying to do that process. So I needed to actually write this as an asynchronous LibUSB driver which it does support the Rust support for it really isn't there but using some of the packages I was able to you know get the right functions from the library and implement some of the higher level stuff myself. And what that ended up being is a working asynchronous driver that handles fairly high data rates on all those platforms which is really nice. I'm still amazed that it worked as well as it did. On the software side you know Rust is really good for writing that system software where you need the low level but I'll be honest it takes a lot of effort to write it. You're fighting the board out checker and until you wrap it around that it's hard and it's it just takes more time to write. It aims for correctness but that also requires more keystrokes. So it's good for system software and it's good for this type of driver thing where you want that type of software but when you're writing the hacky little scripts to like send some cam frames you probably don't want to write it in Rust. So Python is sort of the industry standard for those types of hacky scripts I find and the Python can library is a good mature option for can support in Python and it opens the door to a lot of things. So by getting a can to have supported by can Python you can do that UTP protocol through the Python can ISOTP module. You can do unified diagnostic services through the UDS on can module and you can do a lot of stuff through Scapey which now has excellent support for some automotive protocols. So I am able to write a very minimal Python sort of library for can-tact which really only provides like you know set the bit rate turn the device on send frame receive frame and then wrap that in with Python can and then I get support for all sorts of stuff. The way I actually wonder about doing this is also kind of neat. Basically I used something called PY03 which is a poem I think on Python ox trioxide but what that actually does is it lets you generate the Python module from Rust. So you actually use Rust to write the definitions for all the Python objects that end up getting exported. And what that means is it's again one code base all in Rust. There's one line of Python and a setup dot PY file and that's all the Python parts. And I've actually automated this out with GitHub actions. So whenever I do a push to the GitHub repository it will automatically build the pre-built real files for Python with all those options. It builds in all the driver code as well and then it publishes that to PyPy if I tag it with the version. So this way you can actually do pip install contact and lo and behold you should get the contact driver and Python library in one go. And yeah, it opens the door to a lot of different tools. There's also a tool here which I'm going to mention very briefly called Bus Master. It's an open source thing from Bosch on Windows. Cantak support works but unfortunately Bus Master is pretty dead. But one thing that this did result in is C bindings that work on Windows via DLL if other people want to use individual studio. Quickly on building and selling the thing so I had a contract manufacturer based in China that actually assembled the boards for me. It's actually pretty cheap to do this nowadays. If you're interested, I find building the stuff on your own probably not worthwhile unless you're just doing a prototype. Once you're building more than one or two, start looking at CMs. The case manufactured by Polycase and then I personally did all the final assembly here made in Canada or assembled in Canada with foreign parts. And finally I launched through crowd supply so crowd supply if you're not familiar is a pretty great service that will help you launch your hardware product. It's a crowdfunding platform. I set the goal at one dollar because I knew I was going to I already ordered them all so I knew I was going to release it regardless but they let you do some social media around that and race and money. And so if you are doing something where you're not sure you can put it on crowd supply first and then you also get linked up with Mauser which is one of the largest electronics distributors in the world and they'll fulfill your product so you can actually buy the Kantec Pro on Mauser anywhere in the world now which is pretty cool. So just a few words of advice you want to build hardware great awesome just some things to think about bomb or bill of materials cost is critical because everyone needs their cut if you want to sell through Mauser great but you're going to have to expect a certain amount of markup so they can make some money. So your bill of materials cost tends to be that cost basis if it costs you $50 in parts to build the board then you're going to need to be selling it for usually at least two to three times that in order for it to make sense and that's in the low end just because you need to cut all the way along. So I recommend with this stuff honestly build it for yourself. Open source hardware is not a good business you won't make a lot of money selling open source hardware tools in my experience but if you build stuff that you think is cool other people probably will too there's a lot of people on the internet and there's probably a bigger audience for it than you think it can also help you get some help from stocks and things like that. Don't build in a vacuum so show other people what you're building get the feedback and how people debug for you because it's really hard to do that without help and chip shortages suck right now we're in a really big chip shortage so hopefully we'll get out of it soon but right now it is hard to find parts for a lot of stuff hopefully that's not the case for a while. Now I have a few demos here I am very white on time I think I'm going to unfortunately roll through here but you can check out the GitHub repository for Cantact and it has those examples that I would have run in place so the next steps for Cantact the Rust CLI needs some improvements it could use some more tools I want to get the FD version of that driver merged and I want to build a breakout board so you can plug OBD and different things into the Cantact without having to mess with cables so that's why a lot of time thanks a lot for taking the time to listen thanks for the NorthSec people for having me it's always an awesome conference and I hope to see you all in person next year once again there's all the ways you can find me and looking forward to the discussion where you can ask your questions in an hour or so here