Peeking Inside a Wireless CarPlay Android Auto Receiver

Once I disassembled the navigation hood of my 2004 Mazda RX-8, I discovered the wireless CarPlay/Android Auto receiver I wanted to install would not fit. It’s a few millimeters wider than the existing navigation screen and the bezel had no room to spare. I would have to cut something to make everything fit. Between the cheap device I could easily replace with another Amazon order versus Mazda interior trim piece, I prefer to cut the cheap device. I will take the receiver apart to look inside. Since I’m just scouting for trimming potential, this is not a full teardown.

Its enclosure was held with just clips, no fasteners. It was a matter of jamming enough opening picks into the gap to release a row of clips on one edge. Once that’s accomplished, remaining clips released easily.

It’s pretty minimalist inside, as fitting for a low cost device. Just a single main circuit board, the screen, and a few supporting components.

I had half expected a PCB antenna, but happy to see a short little thing glued to the case and attached to the circuit board with a removable connector. This potentially give me more options. Either in relocating this antenna elsewhere or replacing it with a different antenna in the hopes of improving reception. I will use this one as-is until I have a reason to tinker.

Looking at this antenna, I felt something was wrong and it took a few seconds of thought to realize what: when I look at similar antenna during computer teardowns, they’re always carefully placed outside of metal RF shielding. This device appears to have no metal shielding at all. In fact, now that I am looking for them, I noticed there were no label for make and model number and, most important for this discussion, no FCC ID listed. Is this thing even legal?

On the upside, the lack of metal shielding meant it’ll be easier to cut this enclosure backside to any shape I need to mount it in my navigation hood. And the lack of components meant I won’t damage anything on the way.

I saw quite a few unused provisions on this circuit board. The terminals labeled “-” and “+” are apparently provisions for a battery. I’ll be running this on car power so I don’t care. More interesting to me are two surface mount buttons that are not accessible when this unit is closed up. What are they for?

Down in one corner I see the embedded microphone and, a few centimeters away, a cable leading to the screen. I thought this might be backlight power, but terminals labeled with I2C style “SCL” and “SDA” tells me this is more than just supplying light. This is probably the capacitive touch controller.

Flipping the screen open, I could confirm it is indeed the touch controller. The good news is that capacitive touch digitizer is roughly the same size as the LCD, so they’re safely out of the way from trimming operations. The bad news is the front of this unit is a single sheet of glass bonded to the front of this enclosure. Given the price point I had expected a sheet of clear plastic, but it’s glass.

The only method I have of cutting glass is the “scratch a line and bend” method. I don’t have a handy diamond to scratch glass, though maybe one of my carbide tipped cutting tools can do it. More problematic is the bonded piece of plastic which makes the “and bend” part very difficult to do neatly. I’d likely shatter something else in the process.

Looking at this situation, I decided I couldn’t avoid cutting into Mazda interior trim piece. But I’ll try to minimize the damage. On the device side, I’ll cut away as much of the plastic as I could. Whatever is left (the glass and its plastic backing) will need only a narrow slot to slide in sideways.

Disassembling Navigation Hood from 2004 Mazda RX-8

A car’s interior is a pretty awkward place to work. As soon as I freed the navigation LCD assembly from my 2004 Mazda RX-8 dashboard, I moved my project to a flat work area. It was lined with a clean soft white towel to reduce chances of something getting scratched up.

I immediately unclipped the center speaker mesh, because that looks extremely fragile. I set it aside in a safe out of the way location. In hindsight, I didn’t need to bother. This large panel can be freed easily enough.

There are two buttons on this assembly, one on either side of the retracting hood and each secured with a screw. The retracting hood itself is an assembly I can unscrew as well.

The electromechanical assembly can then be separated from the large cosmetic panel.

I was encouraged by what I saw on the side. I can see the retraction gear mechanism and two details that would help me reassemble this later. First, the motor has a D-shaped shaft (round with a flat section) so the gear can be removed and reinstalled in the exact same place. Second, there is a small white mark on the gear for alignment with a similarly marked tooth on the track.

I also saw the retraction hinge is hollow, with a beefy ground wire through the hole on this side. This will help me route wires for my project. But all I see here is a solid grounding wire. Where is the wiring for everything else?

I found my answer after undoing the four screws (two on each side) holding the hinge in place, freeing the hood itself. Now I can clearly see a wide flat FPC (flexible printed circuit) handling the majority of electrical connections between the base and the hood. I can also access the two screws holding the hood lid.

Once hood lid was removed, I have a clear view of the retraction mechanism sitting behind the LCD screen. I would have expected the retraction mechanism to live in the base and not in the hood, but here it is taking up valuable volume inside. I also didn’t expect it to be controlled by the LCD circuit board, but I learned this was the case from RX-8 owner forum of others who have done this before. I had originally thought I could just remove everything inside the hood but, if I want to maintain the hood retraction capability, I’d have to keep the LCD circuit board for its little side function.

Removing the motor assembly allowed me to open up the stout metal shield protecting the factory navigation LCD screen. This shield is the destination for that beefy ground wire I saw routed through the hinge. Using my multimeter, I found three of the FPC ribbon cable connections had continuity to the beefy ground wire, but they were apparently not enough. It sure looked like Mazda engineers were forced to install additional grounding during vehicle development. I wonder what the problem was.

Speaking of problems, this section of the LCD circuit board has me extremely worried. Based on CAUTION! HIGH VOLTAGE! warning printed on the circuit board, big beefy components nearby, and thick wires leading to the display, I deduced this is for a CFL (compact fluorescent) backlight. My car was apparently too old for a LED backlight.

A high voltage transformer like this assembly will throw off a lot of noisy electromagnetic signals, the kind that would mess up a capacitive touchscreen. The factory screen is not a touchscreen so it has no worries on that front, and the stout metal shielding would have mitigated interference with other components. But I’m going to swap out the screen and keep this circuit board to manage the retraction motor, and this circuit might be trouble.

And that’s not my only trouble. After removing the factory LCD assembly, I measured its width at 177mm including the sheet metal cage. My wireless CarPlay/Android Auto receiver is wider at 190mm and would not fit in between mounting posts molded into the retracting hood.

In order for this to fit, I will have to cut something. RX-8 owners who posted their tablet installation procedures on the RX-8 forums usually cut these mounting posts. I hesitate to make destructive modifications to my car. I would much rather cut into the inexpensive receiver, because it would be much easier and cheaper to buy a replacement off Amazon if I make a mistake. But before I start cutting, I should look inside to see if there’s anything critical along its edges.

Removing Navigation LCD Assembly from 2004 Mazda RX-8

After reviewing RX-8 owner forums, I feel I have a good idea how to tackle my project: swap out my 2004 Mazda RX-8’s factory navigation system LCD screen for a modern wireless CarPlay/Android Auto receiver. The first order of business is to extract that existing factory navigation LCD assembly, which required taking apart many pieces of interior trim. Such extensive disassembly was needed because Mazda designed the center console as a series of overlapping pieces. Each one had to be removed to uncover fasteners for the next one.

The first step was easy: unscrew my manual transmission shift knob. (I have no idea what this looks like for RX-8 with automatic transmission.)

Upper console panel surrounding the shifter is held only by clips, so it can be loosened by careful prying. No screwdriver necessary. Once loosened, I unplugged three electrical connectors: the navigation control panel, and seat warmer switches for driver’s side and passenger side seats.

A salute to the Mazda engineers who put in extra effort to make it extremely difficult to mix up the driver-side and passenger-side seat warmer controls. Not only are they differentiated by color (black for driver’s side and white for passenger side) they are also physically keyed differently. The driver’s side had two shallow channels, the passenger side had one deep channel and one blocked channel.

Now we can access the two screws holding the ashtray panel in place.

There are three electrical connections to the ashtray panel. One for the cigarette lighter socket, one to illuminate that socket, and one to illuminate the tray. I could not extract the tray illumination assembly, but I eventually figured out it was much easier to remove the bulb.

With the ashtray panel out of the way, we can access two screws holding the center panel (with audio and HVAC controls) in place.

Before we can slide the audio head unit + HVAC controls module out, we have to take a side detour to the driver’s side footwell. Just under the steering column is a plastic panel held by clips, and behind it a metal bracket held by these four screws.

Then we can stick our head down there. Looking towards the center console, we can see a single 10mm bolt in the side of the audio head unit that must be removed. Don’t get distracted by the two nuts. Theyare much more easily accessible but will not help with this task.

Once that bolt is removed, I pulled on the panel to release four clips at these marked locations. Because this panel is glossy black, I was wary about using prying tools and didn’t use them. This was a mistake: in order to loosen the top two clips, I pulled too hard on the glossy panel and damaged it. (Though I wouldn’t realize it until later.)

Once loosened, I reached my hand behind this panel to unplug all the electrical connectors. From top to bottom:

  • Connector to the LED status screen.
  • Small round AM/FM antenna connector.
  • Large rectangular connector for power, speakers, etc.
  • Beefy connector directly behind the fan speed knob, presumably for fan motor.
  • Smaller connector, presumably for remainder of HVAC controls.

After extracting the audio/HVAC panel, I could access two screws holding the center ventilator grille.

Once that’s removed, I could finally access the two screws holding the navigation LCD unit panel.

Beyond those two screws, the panel is held by copious clips all around. Loosening them allowed access to unplug three electrical connectors from the navigation LCD unit:

  • Beefy grounding cable
  • Power and communication with the navigation computer between the rear seats.
  • Center console control panel that sat just behind the shifter.

The navigation LCD assembly is now freed.

A view of the cavity formerly hosting said assembly. This view also shows location for all the clips.

Someone more familiar with this system might be able to remove the navigation LCD panel without fully disassembling everything as I did. For example, in hindsight the shifter surround panel could probably move enough to allow access to ashtray panel screws without disconnecting seat warmer and navigation control panel connectors. But I didn’t know that at the time, and I was curious to see what’s behind these panels.

Next, the newly freed navigation LCD assembly is moved to a more comfortable work area for further disassembly.

Online Resources for RX-8 Navigation Project

I bought a cheap wireless CarPlay/Android Auto receiver and preliminary tests show it should work well if I can install it in place of the factory navigation screen in my 2004 Mazda RX-8. This is not the type of procedure covered by Mazda’s official workshop manual. I would need to check the RX-8 owner’s forum at https://rx8club.com to see what others have done before me. One advantage of a twenty-year old car is twenty years of other people sharing their stories of tinkering with theirs.

Surprisingly, I didn’t find anybody doing the exact same thing. Perhaps standalone wireless receivers are too new for this DIY crowd? There were plenty of threads about CarPlay/Android Auto audio head units with the Metra kit, like this relatively recent example, but I’ve already decided I’m not going that route.

The closest matches were from people who installed a 7″ tablet in their factory navigation hood, as my new wireless receiver is basically a 7″ tablet. I found several threads and many of them referenced one of these two pioneers: one project installing a Samsung Galaxy Tab 2, and another project installing a Huawei MediaPad. Both of these were long threads with reference pictures and many good questions followed by valuable answers.

For connecting tablet audio to the car, later RX-8 came with an auxiliary audio input jack. Early RX-8 did not but this is a well-solved problem. People reverse engineered the audio head end circuit so we can get an auxiliary audio port that the car believes to be the optional cassette tape deck or minidisc player modules. Implementations range from an Arduino-based DIY solution to commercial products for sale. I bought and installed a Sylfex AuxMod Basic years ago, a product that has now been discontinued. Current-day alternatives include the GTA adapter kit.

My wireless CarPlay/Android Auto receiver came bundled with a backup camera. I’m going to postpone that project until a future phase but, when I get around to it, there are forum threads I can reference as well like this one.

Armed with knowledge, I opened up my toolbox and started dismantling my center console.

First Impressions of CarPlay and Android Auto Receiver (TTXSCAM T86)

After I quickly reviewed everything that came in the box of this TTXSCAM T86 CarPlay/Android Auto receiver I bought via Amazon (*) it was time to power it up to see it in action. There were two test configurations. The first was powered by a solar charged battery and desktop speakers, the second round were powered by my car’s battery and output to my car’s speakers via an aftermarket audio input port. (Sylfex AuxMod Basic, now discontinued.) My observations are as follows:

The first thing I measured was the visible display area, and it was good news: it almost matched the size of stock navigation screen bezel. 4mm narrower in width and 3mm shorter in height, this is as close of a match as I could hope for. Mounting this inside the existing navigation hood would leave only a negligible black border.

When booting up, the screen displays this image which I think depicts a McLaren 720S. I want to change this image to maybe the Mazda logo or a picture of my own car, but I couldn’t figure out how. The device also emits a little musical chime on startup on both its internal speaker and the audio line-out port. I didn’t find a way to change or silence that, either. Neither of these boot-up behavior is a deal breaker but customization would be nice.

The device home screen has a few functions, the only one I cared about was “Android Auto”. Pairing it with my phone as a Bluetooth peripheral enabled Android Auto. Scrolling around Google Maps on this device, I found the system responsiveness to be merely acceptable. There’s a noticeable delay between input and response, and scrolling animations are chunky. It feels roughly on par with <$100 USD Android phones commonly sold with prepaid cellular services. I am optimistic the device’s sluggish response won’t matter, because if I want to do something like putting in a new address for navigation, I can use my (much more responsive) phone’s screen.

Once connected to my phone, this receiver will try to reconnect to my phone every time it powers up. I counted ~30 seconds between turning on power and projecting information from my phone. It’d be nice if this was faster, but ~30s should be fast enough for everything to be up and running by the time I’ve backed out of the driveway.

Speaking of which, I also did a quick test of the bundled backup camera. I just connected the wires, no mechanical mounting. The camera is just sitting on the floor looking at my feet. With the camera connected and the signal wire tied to input voltage (emulating the power line of an illuminated reverse gear light bulb) it only takes ~10 seconds between screen power-on and showing backup camera view. This is roughly on par with the amount of time I allow the engine to settle down to idle before shifting into reverse, so I’m also filing it under “would be nice to be faster, but probably fast enough” as well.

When using audio line out, to my car’s audio input port, I could control sound volume with the existing sound volume control knob or steering wheel controls. This worked as expected with no surprises.

Screen brightness is another story. The factory navigation system automatically adjusts screen brightness based on an ambient light sensor and a signal wire indicating if headlights are on. I can’t tell if there’s a brightness sensor built into this device, but it definitely doesn’t have the headlight state. I have to manually adjust brightness to fit ambient light. I neglected to look for this aspect when listing my shopping criteria, oops. I’ll have to see if this bothers me enough to make me pay for an upgrade.

I’m encouraged by the almost-perfect screen size fit, fast-enough startup time, and integration into existing volume control. I can probably learn to ignore the startup image and chime. I’m not so sure about screen brightness behavior, but that’s not an immediate deal breaker. This cheap thing is not excellent, but it seems good enough to meet my needs. Before I take my car interior apart, though, I should do my homework and study information available online.


(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.

Unboxing Wireless CarPlay and Android Auto Receiver (TTXSCAM T86)

I wanted to add CarPlay/Android Auto capability to my 2004 Mazda RX-8 by replacing the screen of the ancient Mazda factory navigation system. I picked out a standalone wireless receiver with features I liked and a physical size that I hoped would fit. When my TTXSCAM T86 (*) showed up, there was a satisfying quantity of stuff in the box.

I immediately went to the manual (which called the device a T86MP5) and found it to be nearly useless. A thin booklet of 22 meager pages that didn’t cover basic information like installation or anything about the backup camera. I think I’m on my own to figure out most of this device.

It came with two sets of mounting hardware. One for the top of the dashboard, either by the included double-sided adhesive or four fastener holes. And the other is a suction cup mount either to the windshield or to the included a smooth plastic disc, also with double-sided adhesive. I will mount this device inside a piece of existing interior trim, so I won’t be using either of these mounting arms.

It also came with a 3.5mm stereo audio cable, and a power cable that plugs into the de facto in-car power source form factor that traces its origin to a cigarette lighter. The device end of this power adapter is a USB type C plug, but this adapter is not a full USB PD (Power Delivery) source. It only claims to deliver 5 Volts at up to 3 Amps.

Majority of the parts count are associated with the backup camera. Electrically, there’s a wiring harness long enough to run the length of the car, various zip ties and other cable management tools, even a roll of electrical tape. I didn’t recognize the red plastic pieces and had to search online to learn they are T-tap connectors. Further reading taught me I am supposed to use them to tap into the reverse light power wire, so the system knows to turn on the backup camera.

Mechanically, this package included a license plate bracket and associated hardware to mount the camera top and center above the license plate. I can’t use this directly as-is because the RX-8 has its license plate illumination light centered above the plate, and this mount would block that light with the camera. I will have to modify the bracket, or existing light, or get creative with something else.

I was charmed by the inclusion of a few tools. A tiny screwdriver to work with the small camera-mounting screws, and a large piece of orange pry bar for removing interior trim. Something I’ll be doing a lot to run the camera wiring harness through the car. Looks like a proper backup camera installation will be a lot of work. Fortunately, I can put that off until later. The next order of business is to explore how this receiver works with a benchtop test.


(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.

CarPlay and Android Auto Receiver for 2004 Mazda RX-8

I wanted to add CarPlay/Android Auto capability to my nearly twenty-year old car and as soon as I learned standalone receivers existed, I knew that was the direction I wanted to go. I started looking for a good candidate for installation inside existing navigation hood. It’s a little motorized retractable pod where Mazda housed the screen for the factory navigation system, and fitting into that pod will be the primary physical constraint. In addition to physical size, there are several other evaluation criteria:

Screen

Annoyingly, screen size is the next most important constraint, yet it isn’t something I can confidently determine. I want to buy a unit with visible screen area matching the factory navigation screen, so it fits perfectly in the original bezel, but the exact height and width are never specified. The best I can do is look for a “7-inch class” diagonal screen, excluding significantly larger and smaller screen sizes. I also excluded wide aspect ratio screens like this example. (*) A wide screen is a great idea for sitting on top of the dashboard, the intended use these standalone receivers. Showing more data without being too tall and blocking the driver’s view. But I want to fit into an existing 16×9 aspect ratio bezel, so those novel designs are out.

For the display panel, I personally prefer IPS panels for their color and viewing angles. Some units use a TN panel which will probably suffice. (The original navigation screen was likely a TN panel.) I don’t think they make VA panels at these small sizes, but they would also suffice. And finally, I’m not willing to pay the premium for an OLED panel here. Their stunning contrast ratio would be lost in the interior of a car, and there’ll be a lot of infrequently changing pixels risking OLED burn-in. Making OLED a poor choice for this application.

Most of these 7-in screens list their resolution as 1024×600. This is pretty low by modern screen standards, but it’s going to be mounted in a car further away than my usual computer and phone screen distance, so it might be fine. I’m confident it’ll be an upgrade from the factory navigation screen resolution! If resolution proves to be a limitation, I’ll come back and pay extra for a unit with a 1920×1080 screen.

[UPDATE: It would be nice if the device automatically dimmed the screen when dark. I forgot to look for that in my first device, it’ll be added to the criteria list if I shop for another.]

Touch Input

Capacitive touch technology has taken over everything, I didn’t see any of these receivers listed with a resistive touchscreen. My concern with capacitive touch is their sensitivity to environmental interference. A resistive touchscreen will only react to physical forces. A capacitive touchscreen might be affected by the plastic bezel, mounting hardware, or other electronics in close proximity. But given the lack of non-capacitive options I just have to give it a try.

Camera

Since these things are designed to sit on top of our dashboard, some (like the wide aspect ratio item linked above) integrated a front-facing dashboard camera. Since I want to bury mine inside the factory navigation hood, that feature would be useless for me. On a related note, several included either provision for a backup camera or comes packaged with one. This caught my interest. RX-8 rearward visibility is not great, and I’ve occasionally wished for a backup camera.

Audio

For audio output, these devices all have a little built-in speaker for when they’re sitting on the dash. Since I want to integrate it into my car, I want units with a line-level audio output jack. Some of these units can also act as a FM transmitter so we can tune in with the radio, which might sound better than the tiny built-in speaker but not as good as line-level audio signal.

They all have a built-in microphone for audio input, for use with Apple’s Siri or Google’s Assistant. Some of them have an audio input jack for an external microphone, and some have provision for an external button to activate voice commands. I never use voice input, so this was irrelevant to me.

Wired or Wireless?

I’m torn on whether to go for wired CarPlay/Android Auto or wireless. A wired interface will be immune to RF interference and will charge up my phone while in use. Wireless will be more convenient, and one less cable I have to route under trim panels in the car. I can go either way and if it proves to be a problem, I could buy a unit with the other connection method.

Winner

Criteria above culled Amazon listings down to about two dozen very similar products from brands I’ve never heard of. Not knowing how to evaluate differences, I do what most Amazon shoppers do: sort by price. I then clicked “Add to Cart” for a TTXSCAM T86 (*) which had the following features:

  • 7″ IPS capacitive touchscreen with 1024×600 resolution.
  • Bundled backup camera, no front facing dashcam.
  • Audio-out jack in addition to built-in speaker and FM transmitter.
  • Built-in microphone only. No audio-in jack or voice activation button.
  • Wireless CarPlay and Android Auto

This is a very affordable unit. I thought I would start here and, if I find anything annoying, that would teach me reasons to justify going upscale. Keeping things cheap also means it’ll be less intimidating to modify as needed to fit my car. Once it arrived, I looked over everything that came in the box.


(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.

Standalone CarPlay/Android Auto Receivers Exist

I wanted to put CarPlay/Android Auto capability in my car, which is approaching twenty years old. The known solution displaces factory audio with a double-DIN bay for an aftermarket head unit. I decided against that path, because I wanted to keep the factory audio head unit (and all its electronic and stylistic integrations) intact. Instead, I want to put that capability where the factory navigation system screen sat.

Mazda’s factory navigation screen sits in a little motorized hood that retracts when not in use and keeps a screen close to a driver’s field of view while in use. I liked that position and thought perhaps I could fit an aftermarket unit within that volume. It has enough width and height to match a double-DIN bay, but only a fraction of the depth. This is not a problem because we’re not dealing with CDs or cassette tape mechanisms so modern head units can be very shallow. For example, this unit (*) claims to be a mere 1.77 inches (probably designed for 40mm) deep. Possibly small enough to fit in the stock navigation hood. Another potential candidate is to buy a unit like this one (*) that fits in a single-DIN bay and connects to an external screen. I could mount that screen in place of factory navigation screen and find some space nearby to mount the main body.

I knew these solutions are overkill, because they are full audio head units. Meaning they have their own speaker amplifiers, AM/FM tuners, and many other components that I don’t really need because I’m keeping Mazda’s stock audio head unit. I had searched for head units because I didn’t know any better, but Amazon search algorithm helped me out: it started suggesting sale listings for standalone CarPlay/Android Auto receivers. I didn’t know these things existed! But as soon as I understood they were available, I ignored the full audio head units. Standalone receivers are even shallower and, I hoped, more amenable to creative mounting schemes. Which of many offerings listed on Amazon would be a good replacement for a 2008 Mazda RX-8 navigation screen?


(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.

Going Off the Beaten Metra Path

My 2004 Mazda RX-8 was factory equipped with an optional in-car navigation system, but the map data and the electronics behind it are now twenty years out of date. Potential upgrade ideas evolved over my two decades of ownership, but I never got around to any of them. Now I’ve decided to give my car a modern (for now) capability: connect to a phone via Apple CarPlay or Google’s Android Auto.

A typical upgrade solution is to replace the factory stock audio head unit with an aftermarket unit. There’s a large selection of CarPlay/Android Auto capable products, like this randomly chosen example Pioneer DMH-W2700NEX. (*) Such replacement is relatively easy for dashboards that conform to the dual-DIN standard for audio head units. Unfortunately, interior design has been moving away from that standardized format, a trend that included my car. Stylistically integrating audio with the rest of interior now hinders my attempted upgrade.

Fortunately, the aftermarket has an answer for that as well, in the form of Metra 95-7510HG. (*) This kit replaces the entire center console panel with a new facade that accommodates a dual-DIN head end. The “HG” suffix has a glossy finish that matches the stock panel, the version without “HG” prefix may blend in better with the rest of the interior which did not have a glossy finish. There’s also a single-DIN variation with a little storage cubby, but that would be too small to accommodate a CarPlay/Android Auto touchscreen. In all cases, we lose the circle themed Mazda styling on the original panel.

The price tag on these kits is far more expensive than a plastic panel and a few brackets, because there’s a fair bit of electronics that have to be installed as well. Remember that interior integration trend? This panel, formerly hosting the audio controls, also hosts the HVAC controls. Plus, sitting above this panel is a single glowing red screen displaying both HVAC and audio status. The Metra kit includes electronics to interface with the HVAC and status display. It also interfaces with the steering wheel audio controls. And finally, a critical safety item: the emergency flasher button is also part of this assembly.

Searching on the RX-8 owner forum, I found many reports that the Metra kit is not a seamless experience. There are complaints about mechanical fit, cosmetic finish, and electrical gremlins in the electronic interface translators. They’re all solvable problems except for the last one: I don’t usually look down that far when driving. My car already has a screen up high in my normal field of view. I want to use that location. Based on the above criteria, I decided against the Metra kit and will try a different route.


(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.

Replacing Factory Navigation for 2004 Mazda RX-8

I am slowly grinding away at learning FreeCAD, hoping to get good enough so I can use it for future projects. There’s not much to write about learning the ropes, so I’ll write about a different project currently underway in parallel. I had recently concluded a cosmetic art car project, removing Plast-Dip I applied to make it resemble Star Wars’ BB-8. Now my car is back to its factory blue color, and I want to tackle an item that’s been on my to-do list for a long time: upgrade the in-car navigation system.

Mazda offered the 2004 RX-8 with an optional in-car navigation system. It was an expensive add-on, but I was young and flush with a tech salary, so I got mine so equipped. This luxury far predated the age of everyone having maps on their cell phones. (Reminder: the first iPhone launched in 2007.) Add-on units from Garmin and TomTom existed at the time, but the factory options were superior for several reasons:

  1. Spoken directions are piped through the audio system instead of a tiny speaker on the dash.
  2. A dedicated GPS antenna with a better view of the sky than a box in the cabin.
  3. It has access to vehicle speed and direction to estimate position if GPS signal is lost.
  4. Does not occupy a power socket and does not require a tangle of wires.
  5. Screen is elegantly integrated with the interior, not a suction cup on top.

I knew map obsolescence will become a problem at some point, but I wasn’t too worried. At the time I had expected to trade the car in for another one in a few years, I didn’t expect to love the car enough to still have it today. A 2004 model year car that I bought in 2003 means the map data was probably compiled in 2002 if not earlier. This is now quite old, and I don’t recall ever hearing anything from Mazda about map updates, for free or for fee.

One advantage of having the optional factory navigation system is that, if I wanted to tackle an upgrade project, a lot of wiring is already in place as well as the factory interior trim pieces to accommodate a navigation screen. But what would this upgrade project entail? The project ideas evolved as the years went on. Early in my car ownership, I contemplated converting the in-car navigation system to an in-car Windows PC running Microsoft Streets & Trips and patched to the in-car GPS antenna. That would have been a hugely complex project, so I never got started. For a simpler alternative, I considered shucking a Garmin free of its factory enclosure and integrate it into the car, but that never happened either. Then online maps like Google Maps got good enough I thought about replacing the factory navigation screen with an Android tablet with Google Maps running offline maps downloaded at home via WiFi. While I procrastinated, data plans got cheap enough for our phones to use live data online. So, I thought about putting a phone mount inside the factory navigation hood.

None of those happened, but I’m finally tackling the project now. The current state of the art for in-car integration takes the form of Apple CarPlay and Android Auto. That’ll be my target but I’m taking an unconventional route.

Facebook’s “Welcome Back” Was Astonishingly Useless

Today, while researching something online, I followed a link that turned out to be a post in a Facebook group. To read it, I had to log in with my Facebook account that I have barely used for several years. I mostly use it for exactly this purpose: “to read that one thing” and quit. But today I was curious to see a few items from people I’ve fallen out of touch with. Maybe I’ll be reminded why I used to spend time on Facebook.

I clicked to see my feed and was surprised at how many times I had to hit “Page Down” to read anything interesting. It was pretty ridiculous. I hit “Home” to go back to the top of the page, which refreshed everything because Facebook wants to show me different ads. This time, I wrote down the posts that scrolled by. The tally: 39 items before I got 5 actual posts by people on my friends list. 5/39 = 12.8% of my Facebook “Welcome Back” were actual content I cared about, and the rest were garbage. (The actual ordering is at the end of this post.)

This is astonishingly bad. My mental impression of Facebook, back when I was active, was 80%-90% posts by real people sprinkled with 10-20% of ads and other uselessness. Now it has flipped completely around. I’ve read that both Facebook usage hours and advertising revenue are going down, but now I see firsthand what’s going on: to increase revenue and engagement, they increased number of things I didn’t ask for, trying to get me to stay online longer so they can make more money. But that is actually having the opposite effect: I’m now less inclined to stick around, so they’re going to make even less money.

Questionable business plan, pathetic execution.


My sample of Facebook feed welcoming me back after a long period of absence:

  1. “Suggested For You”
  2. “Suggested For You”
  3. “Suggested For You”
  4. “Sponsored”
  5. First actual item from someone on my friends list!
  6. “Suggested For You”
  7. “Suggested For You”
  8. “Sponsored”
  9. “Suggested For You”
  10. Second actual item from someone on my friends list!
  11. “Suggested For You”
  12. “Sponsored”
  13. “Suggested For You”
  14. Third actual item from someone on my friends list!
  15. “Suggested For You”
  16. “Sponsored”
  17. Fourth actual item from someone on my friends list! At this point I’m thinking “Well this is significantly worse than before” but I ain’t seen nothing yet…
  18. “Suggested For You”
  19. “Sponsored”
  20. “Suggested For You”
  21. “People You May Know” (I didn’t)
  22. “Sponsored”
  23. “Suggested For You”
  24. “Suggested For You”
  25. “Sponsored”
  26. “Suggested For You”
  27. “Suggested For You”
  28. “Suggested For You”
  29. “Sponsored”
  30. “Suggested For You”
  31. “Suggested For You”
  32. “Suggested For You”
  33. “Sponsored”
  34. “Suggested For You”
  35. “Suggested For You”
  36. “Suggested For You”
  37. “Suggested For You”
  38. “Sponsored”
  39. Fifth actual item from someone on my friends list, with 21 useless items between it and the fourth actual post.

Holy crap, Facebook. My expectations were low, but you’ve managed to sink far below even that. You’ve just made sure it’ll be even longer before my next visit.

FreeCAD Notes: Part Design First Impressions

Watching MangoJelly’s FreeCAD tutorials on YouTube, I learned the power of FreeCAD workbenches and how FreeCAD supports different workflows via different combinations of workbenches. While I can follow along with what’s on screen, that’s different from my own personal workflow that I’ve been using with Fusion 360 and Onshape. And it’s not yet clear if FreeCAD can do the same or if I have to change my personal workflow to fit FreeCAD.

The tutorial’s first example uses the Part Design workbench. It is focused on creating a single part and only a single part: any operations that result in multiple pieces (like cutting a shape in half with boolean operation) will be flagged as an error. It is also focused on keeping individual operations simple and process them sequentially. We create a simple shape then modify that shape with additional operations until we reach the shape we want.

I understand this behavior resembles Tinkercad and is intended to be a more beginner-friendly way to reason about object modeling. But I saw two problems pretty immediately in my brief playtime: first, by building up a long chain of operations, modifying any single step will have repercussions on every step that follows. This workflow aimed a loaded gun at the beginner’s feet, just waiting for the dreaded TNP to pull the trigger. Second, by encouraging individually simple steps, it also encourages scattering part feature dimensions across all of those steps. The size of the overall part might be in the first step, but to find the size of a hole cut in that part we have to dig into the chain of operations to find the cutting operation.

These two observations meant Part Design workbench didn’t make a great first impression on me. I prefer to create few sketches up front with almost all of the information. (Ideally just three: top view, side view, front view.) And then build my parts from dimensions in those few sketches. If I change those dimensions afterwards, I expect to have the parts recalculated automatically.

I didn’t see anything that resembled my preferred workflow until part 12, when MangoJelly goes into “Master Sketch”. The tutorial shows how to use master sketch with Part Design workbench, which should mitigate my concerns with the default workflow.

Putting it into practice, though, is going to take more practice. Trying to use my master sketch in Part Design is continually frustrated by some kind of misunderstanding I have with how references work in FreeCAD. At one point I got frustrated enough to ask: “I wonder if this is easy in Part workbench” and tried to extrude my sketch there.

My fumbles in Part workbench created multiple surfaces instead of a solid shape with four holes, reminding me of another beginner-friendly feature of Part Design: it hides all the surface-related features, keeping things focused on solid 3D shapes. This is good, but I have a lot to learn before I can make Part Design workbench do my bidding.

FreeCAD Notes: Workbenches

After deciding I’ve had enough of a distraction from learning FreeCAD, I started watching a YouTube tutorial playlist by MangoJelly. Watching someone else use FreeCAD is instructive because it is a difficult piece of software to use without some guidance. When I dove to play on my own, I got far enough to create a new FreeCAD document then figuring out I need to launch a workbench. But a default FreeCAD installation has over twenty workbenches to choose from, and no guidance on where to start or even what a workbench is.

After about 4-5 videos into the MangoJelly playlist, I learned a workbench in FreeCAD is a mini CAD package inside FreeCAD designed for a particular task. A workbench generate data for the underlying FreeCAD infrastructure that could be consumed by another workbench, or be useful directly. To use an imperfect analogy: if Microsoft Office were FreeCAD, its workbenches would be Word, Excel, PowerPoint, Outlook, etc. Except unlike Office, we can install additional FreeCAD workbenches in addition to the default list and we can even write our own.

Workbenches make sense as a software architectural approach for a large open-source project like FreeCAD. People with interesting CAD ideas can prototype them as a FreeCAD workbench without writing a CAD system from scratch. As a demonstration of the power of workbenches, I was impressed by the fact entire code-cad packages can interface with FreeCAD in the form of a workbench.

  • There is an OpenSCAD workbench which bridges FreeCAD with OpenSCAD (which must be installed separately) to consume OpenSCAD script and converts the result into an OCCT mesh that can be used by other FreeCAD workbenches.
  • There is also a CadQuery 2 workbench that can be used in a similar way. With the advantage that since CadQuery is also built on OCCT, in theory its output data can be used by other FreeCAD workbenches more easily as OCCT primitives instead of converting into a mesh.

Such flexibility makes FreeCAD workbenches a very powerful mechanism to interoperate across different CAD-related domains. On the downside, such flexibility also means the workbench ecosystem can be confusing.

  • MangoJelly started the tutorial by using the “Part Design” workbench, and a few episodes later we are shown the “Part” workbench. Both build 3D geometries from 2D sketches and have similar operations like extrude and revolve. MangoJelly struggled to explain when to use one versus the other, leaving me confused. I wonder if FreeCAD would ever choose one and discard the other or would it just continue down the path of having two largely overlapping workbenches.
  • A cleaner situation exists with the “Raytracing” workbench which has not been maintained for some time. There now exists a “Render” workbench with most of the same features. Thus, the unmaintained “Raytracing” will no longer be a part of default FreeCAD installation after 0.20. This is perhaps the best-case scenario of FreeCAD workbench evolution.
  • But “Part” vs. “Part Design” is not the only competition between similar FreeCAD workbenches. There’s no single recommended way to build multipart assemblies, something I would want to do with a Sawppy rover. As of this writing the FreeCAD wiki describes three viable approaches each represented by a workbench: “A2plus”, “Assembly3” and “Assembly4”. I guess evolution is still ongoing with no clear victor.

Learning about workbenches gave me a potential future project idea: If I build a future version of Sawppy rover in FreeCAD, would it make sense to also create an optional Sawppy workbench? That might be the best way to let rover builders change Sawppy-specific settings (heat-set insert diameter) without making them wade through the entire CAD file.

That’s an idea to investigate later. In the meantime, I should at least learn how to work with the Part Design workbench that’s used a lot as in MangoJelly’s YouTube tutorials.

FreeCAD 0.21 is Coming Soon

I liked the potential promise of doing CAD via code instead of drawings, but current implementations left me unconvinced. Partly because today’s existing code-cad solutions are built on OpenSCAD (I’m not a fan) and partly because it is a huge change in mindset. I might find motivation to give it an honest effort in the future, but for the immediate future I’ll retreat back to FreeCAD and the sketch-based workflow I’ve been familiar with. Part of this decision came from getting a sense of FreeCAD’s direction in their “What’s going on at FreeCAD?” communications.

The biggest question I had is about the infamous topological naming problem. (TNP) This always comes up whenever people discuss switching from a commercial closed-source CAD package to open-source FreeCAD. Opinions range on a wide spectrum from the snobby “only dumb users run into TNP” to “widespread adoption would not be possible until TNP is mitigated” to dismissive “TNP exists because FreeCAD is not a serious project”.

I don’t personally have an opinion on FreeCAD TNP, since I haven’t used it very much yet. But I know enough to be aware it’s not exclusive to FreeCAD. Many other CAD packages have problems along those veins to varying degrees. For my Sawppy CAD file in Onshape, part geometry changes are sometimes followed by notifications of failed fillet operations. Or worse, fillet operations that don’t fail but went someplace unexpected.

But my opinion is not as important as the opinion of the people behind the project. Do they even consider TNP to be a problem that needs solving? Thanks to “What’s going on at FreeCAD?” I learned the answer is a definite YES. In fact, they consider it one of the (if not THE) top problems that need to be solved before they can declare FreeCAD version 1.0.

I don’t understand enough FreeCAD internals to understand how they intend to address TNP, but there IS a plan, and the project is at a critical stage. The underlying support infrastructure is in place, but starting to utilize that infrastructure across FreeCAD will likely degrade performance until everything is done. This will be the next public release. It won’t disrupt users who aren’t part of making the great TNP fix, while providing a stable foundation for people who are. Allowing them to implement and test TNP solutions. (And if things go seriously wrong, it leaves the option open to rip out that infrastructure and try a different approach without breaking future versions.) Since TNP is not fixed yet, the next release will not be 1.0. It’ll just be the next increment: 0.21.

I first started looking at FreeCAD shortly after 0.19 released and online resources (aimed at 0.18 and earlier) were in turmoil working to update. Today, 0.20 had been out for over a year and most resources have stabilized. I should take advantage of that and learn 0.20 as quickly as I can before 0.21 causes another round of disruptions.

So where should I start? There was a recent Hackaday post about FreeCAD, which elicited the usual cacophony of comments arguing about TNP. But in between the noise I noticed multiple recommendations for MangoJelly’s YouTube tutorial series. Video tutorial is not my preferred format, but if it’s a popular place to start, I’m willing to give it a shot.

To Code-CAD or Not to Code-CAD

CadHub is an advocate of defining 3D models using lines code instead of the more traditional interactive UI descended from pre-computer drafting boards. It holds a lot of promise and it linked to several projects making those ideas real. The problem is they’re built around OpenSCAD which, while not as bad as I thought, is still hobbled by some fairly fundamental limitations. I wouldn’t say I’m a convert to the cause just yet.

I am happy to see these code-cad projects implementing some of my wishlist for collaborative CAD capabilities. However, taking a step back, I noticed there is no fundamental requirement linking the two. Take the example of branching and merging: this is a valuable feature that has been implemented in Autodesk Fusion 360 and in OnShape, neither of which are code-cad systems. Similarly, there’s nothing fundamentally impossible about adding automated drawing regeneration, integration with documentation systems, etc. to non-code-cad systems.

I will admit it is easier for code-cad systems to implement such features in the context of git. Since code-cad is based on code and git is specifically designed to work with code. There’s a barrier to climb for non-code data files, but git can be used to version control non-text files like images. Doing so restricts conflict resolution to granularity of entire files: we have to choose one file, or the other, and couldn’t merge between them like we could with text files. Or at least, that’s the situation by default. I’m not familiar enough with the git protocol to know if it’s possible to patch in a binary file format merging mechanism. I do know it’s possible to introduce a binary file change difference visualizer, because GitHub offers support for select non-code file formats.

But there’s more to a collaborative information management system than git, as shown by Fusion 360 and Onshape. While code-cad is A way forward to reach items on my wishlist, it may not be THE way forward. This little research tour has been extremely educational, but I should get back to studying FreeCAD.

OpenSCAD Gems via CadHub

CadHub is an advocate for the general idea of 3D CAD models built from lines of code instead an electronic representation of a drafting board. This approach (“code-cad”) holds many promises of meeting my wishlist for an open-source collaborative CAD solution. While theoretically applicable for all code-based CAD solutions, the current reality is almost exclusively built around OpenSCAD.

I briefly dipped my toes into OpenSCAD for a bit, but I was really turned off when I learned the prescribed method to perform a fillet operation in OpenSCAD is to use operators like Minkowski sums and convex hulls. They are conceptually straightforward but in practice it takes a long time to chew through the math. Making matters worse, OpenSCAD’s CSG kernel is limited to a single thread underutilizing modern multicore processors. In contrast, the OpenCascade 3D kernel can easily handle fillets and has partial support for multicore computation. (Whether that capability is enabled in FreeCAD, CadQuery, etc. is a separate issue that depends on their respective OCCT integration.)

Despite my distain I have to admit such theoretical superiority has to be balanced against OpenSCAD’s real-world advantages that are already up and running. CadHub blog talked about integrating code-cad into software CI/CD pipelines. That page linked to two projects which have already put the concept into practice: OpenFlexture Microscope and a DIY Split-Flap display. Both of these projects define their 3D designs via OpenSCAD, enabling automation to keep their project documentation in sync. This is pretty awesome. And some OpenSCAD users shared the same objections I do, except some of them actually helped solve the problem. CadHub itself has something called the “Round Anything” library that makes some OpenSCAD fillets (especially internal fillets) less painful.

But those are still just workarounds for what I see as results of fundamental OpenSCAD design decisions. Even CadHub, advocate of code-cad in general and OpenSCAD specifically, admits there are significant downsides as tradeoff for OpenSCAD upsides. Despite its actual proven advantages, I still think it’s pretty unlikely for me to put serious effort into using OpenSCAD. Partially because I’m not even sure code-cad is the only way forward.

Window Shopping CadHub

While window shopping a few different projects for generating CAD models in browser, including replicad, I came across the occasional mention of CadHub and decided to take a look. I like what I see, but the project seems to have lost momentum.

The most visible component of the project is a browser-based interface for code-based CAD, much like what Cascade Studio has built, but generalized across multiple systems. It supports OCCT-based CadQuery as well as OpenSCAD with its own CSG system. But that was merely the first step on the list of ambitions. Its documentation homepage listed how code-based CAD can realize many of the items on my collaborative CAD wishlist, including automatic design verification and visual change comparison (diff) tooling. These and many other long-term ambitions are described on the “Blog” side of documentation page, along with this very informative survey of code-based CAD solutions.

So that all looks great in theory, how does the reality look? And sadly, things don’t look as rosy there. Despite all the theoretical advantages of code-based CAD in general, it appears that only OpenSCAD has found any significant adoption and I’m not a fan. (That’s a separate post I should write up.) On paper, CadHub supports CadQuery as one of several kernels, but as of this writing CadQuery capability has been disabled. The “it’s just Python” power of CadQuery became its downfall: since running CadQuery requires a Python environment, people have abused CadHub to do non-CAD things like trying to run security exploits or mine cryptocurrency using free CPU cycles. This sounds very much like the reasons Heroku free tiers went away.

Another “things didn’t work out” problem with CadHub is a consequence from the fact it presents a web-based IDE. Which is great until it tries to work with something that has its own web-based IDE like Cascade Studio. After multiple hacks trying to get the two systems to work together, CadHub threw in the towel.

These and other setbacks must have been discouraging, and probably contributed to the project losing momentum judging by its GitHub commit history. In 2021 it saw updates almost daily, sometimes multiple commits a day from multiple authors. It was still quite active going into January 2022, but the rest of 2022 saw only four commits. The most recent update was in January 2023, the lone 2023 update to date.

This is unfortunate. I really liked where this project intended to go, as it aligns with much of my own wishes. Since it is open source, I suppose I could fork the project and see if I can run with it, but I’d need to learn a lot more web development before I can even understand what’s already been done. Never mind trying to add to it. Even if I don’t use CadHub directly, though, it taught me a lot more about OpenSCAD I hadn’t known before.

Window Shopping replicad

I thought Cascade Studio was a very interesting project, providing a 3D model environment that can run entirely in the browser. Even offline if desired, as a locally-installed PWA. It is a code-based design system like CadQuery. While they all build on top of OpenCascade Technology kernel, the code-based API differences are larger than just the difference in language. (Python for CadQuery, JavaScript for Cascade Studio.) I found a lot to like, but also a few implementation details that I’m not fond of. That’s OK, there are other projects out there, including replicad. (Hackaday post.)

Both replicad and Cascade Studio run entirely within the browser thanks to OpenCascade.js, which compiled the 3D kernel into WebAssembly. And despite the fact they both wrap OpenCascade concepts with JavaScript, their API are different. Reading through replicad documentation, I learned their target scenarios are also different: Cascade Studio aims to be a full in-browser 3D model environment, presenting the JavaScript code as well as a 3D rendering. replicad is intended for people to share their designs online for others to use, by default presenting just the 3D object and the underlying code is not directly visible. But the viewer can make changes to model parameters and have the shape recomputed. This reminds me of Thingiverse Customizer, which is limited to OpenSCAD models.

Cascade Studio had the “Slider” UI option to allow customization as well, and one difference immediately jumped out at me: Cascade Studio allows the design author to specify maximum and minimum values for the slider, but replicad doesn’t seem to allow setting limits on model parameters. This seems like an oversight.

One significant advantaged I noticed in replicad API is their way of avoiding FreeCAD’s topological rename problem that Cascade Studio also seems to share. Instead of specifying entities like edges with names or numbers, replicad has a system called finders to find elements that meet a specified set of conditions. For example, it allows finding all edges at a particular Z height. Allowing us to apply a fillet without worrying about their specific names/numbers. This makes replicad closer to CadQuery, specifically with its concept of selectors.

I didn’t see any references to constraint solving. Based on some of the examples, I believe the author expects us to write JavaScript code to compute what we need directly within our 3D object design code. It’s a valid approach, but maybe not my favorite answer. I also didn’t see any references to creating multipart assemblies. Perhaps I could find an answer in a larger-scale overview like CadHub.

Window Shopping Cascade Studio

Describing 3D objects with Python code is CadQuery’s goal, something I find interesting for later exploration. Browser access is possible by running CadQuery in Jupyter Lab, making it accessible to low-end Chromebooks, but that still requires another computer serving Jupyter Lab. What if everything can run entirely standalone within the web browser? That is the laudable goal for Cascade Studio. (Hacker News post) (Hackaday post)

Projects like Cascade Studio were made possible by the OpenCascade.js project, which compiles the open-source OCCT kernel code into WebAssembly (WASM). No more hassling with separate build chains for a Windows/MacOS/Linux desktop apps like FreeCAD, now a 3D model system can run entirely within the browser no matter the underlying operating system. There must be some performance cost tradeoffs for such flexibility, but I haven’t dug deeply enough to know what they are.

Looking over how Cascade Studio was built, I see it leverages a lot of other open modules beyond OpenCascade.js. Like using Three.js for rendering the 3D model, and Monaco for the code editor. Oh right — code editor. Cascade Studio also describes 3D objects with code, except here it’s a JavaScript-based interface on top of OCCT concepts. It also leverages a lot of web technologies, like conforming to Progressive Web Apps (PWA) requirements so it can be installed locally to run entirely offline.

A valuable source of information is an unofficial Cascade Studio manual, written by a fan and not the author. (If the author wrote instructions, I have yet to find them.) It tries to cover everything a person would need to use Cascade Studio, with some basic 3D model concepts and basic JavaScript concepts. But what I really appreciated was the condensed digest of this fan’s experience with Cascade Studio, documenting many minor quirks and — even more valuable — their workarounds.

I was really enchanted by Cascade Studio possibilities until I got to the fillet edge section. Our code code needs to provide a reference to the object (obviously) and a list of edges (expected) by number (record scratch noise.) Wait, where would those numbers come from? We have to use the GUI to click on individual edges we want, the GUI will in turn display a number for each, which we can then write down to give as parameters. I inferred these numbers were generated out of the OCCT kernel and are subject to change in response to changes in the underlying geometry. If so, this would mean FreeCAD’s topological naming problem is present here, except as a topological numbering problem. Is there anything about Cascade Studio’s code-based model that would mitigate this? I don’t have an answer for that.

Constraints were a notable absence from this manual. I want a mechanism to specify things should be parallel or perpendicular, lines that should be tangent to arcs, helping to capture intent of the underlying geometry. It appears some constraint solving capability is part of OCCT, but it might be missing from Cascade Studio or at least missing from the unofficial manual.

Also absent were information on working with assemblies of parts. Onshape had the concept of “mates” to describe physical relationship between different parts. Sawppy’s suspension articulation were captured as rotate mates, with a single degree of freedom rotating about an axis. There are other types of mates, “slide” is a single degree of freedom translating along an axis, “fasten” with zero degrees of freedom, etc. I saw nothing similar here.

One item I thought was very interesting was the Slider control, which allows me to declare a user-adjustable parameter on screen. For Sawppy, the most value application of such a feature is letting a rover builder adjust the diameter of holes for heat-set inserts. This has caused grief for multiple Sawppy builds, because the outer diameter of M3 inserts is not standardized and every 3D printer prints to a slightly different tolerance. It can even be argued that most rover builders don’t care about modifying the design significantly, most would only need a few sliders to dial in a design to suit their tools and parts. If that is indeed the primary scenario, perhaps replicad would be a better tool.

Window Shopping CadQuery

When I started learning about FreeCAD, I also learned about its 3D modeling core OpenCascade Technology (OCCT). OCCT is not exclusive to FreeCAD and it forms the core of several other open-source CAD solutions, each implementing a different design intent. In the time I’ve been keeping my eyes open, I’ve come across several projects that might be interesting.

First up on this survey is CadQuery, a Python API on top of OCCT. (Hackaday post) Which is very interesting considering FreeCAD already has a Python API. From a brief look, those two APIs have different intentions on how to expose OCCT capability to code-based construction. FreeCAD’s Python API primarily enable macros, scripts, and extensions to supplement projects created in FreeCAD UI. CadQuery removes the need for graphical UI entirely.

But this is not the whole picture. It’s also possible to run FreeCAD without an UI, so I will have to dig deeper to really understand the tradeoffs between their two approaches. CadQuery actually started out as something built within FreeCAD. CadQuery became its own independent project when the team started feeling constrained by FreeCAD limitations around selection. That tells me CadQuery is working to get away from the well-known FreeCAD problem of topological naming.

Being code-centric means a CadQuery design is a Python program and can take advantage of all the software development tools available. Which satisfied my CAD wishlist item for Git-like ability to fork, pull request, etc. The problem is “diff”, which will show the Python code changes but not a visual representation of those changes. This can probably be solved by using CadQuery to process the before/after views and render the difference between them. (Such a tool may already exist.)

Since CadQuery is not dependent on any graphical user interface, there are multiple ways to play with it. CQ-editor is a native desktop application letting people use CadQuery in a similar manner to OpenSCAD. Another way is to work with CadQuery Python code in a Jupyter notebook, giving it a browser-based interface. And the one that really caught my eye: cq-directive, which runs as part of the Sphinx documentation generator. In theory this allows diagrams in documentation to stay in sync with the CadQuery design files. Keeping CAD in sync with documentation would resolve one of my recurring headaches with Sawppy documentation.

CadQuery looks like a very promising venue for investigation, but trying to go hands-on was stymied by Python versioning support. As of this writing, the latest public version of Python is 3.11 and it’s been around long enough most infrastructure like Jupyter Lab has updated. However, CadQuery is still tied to 3.10 and not expected to move up to 3.11 until later this year. Version conflict is nothing new in the Python world and can be solved with a bit of time, but I chose to put CadQuery on hold and read up on other options starting with Cascade Studio.