A rugged, reusable CAN FD board — would you want this?

[jlaustill]

I'm developing a rugged CAN FD transceiver module, and I'm curious whether anyone else would want one.

I'm trying something different: a dev board that's production-ready, with proper line protection built in, breadboard-friendly, and on castellated edges so you can reflow it onto a carrier board with a hotplate or oven — and just as easily desolder it to reuse it. I waste so much money on dev boards that are a nightmare to desolder because of the pin headers — lifted pads, burnt boards, you know the drill.

A few specifics:
- MCP2562FD transceiver — CAN FD (2–8 Mbps)
- Runs at 3.3 V and 5 V logic via VIO (no level shifter) — pairs nicely with a Teensy 4 + FlexCAN_T4
- Layered protection for harsh/long-line use: TVS, common-mode choke, TBUs, and gas-discharge tubes to chassis
- ~35 × 25 mm, 10 castellated pads

If there's interest, I'm considering having a batch made and selling them — fully open source (CC0), with complete schematic and production files for real right-to-repair. If I disappear, your board is still yours to make and fix forever.

Schematic + files: link to github
[photo attached]

I'd love your take: what would make this your go-to CAN board? Is the form factor a winner — and if not, what would you change? And where do you land on leaving bus termination off the board (my plan — termination belongs on the bus, not the node and I get sick of desoldering a resistor off of every board I buy haha)?

 

[OIEIEIO]

I would order a bunch

I like the direction of this board. I’m using the Teensy 4.1 as a companion processor alongside ArduPilot flight controllers, experimenting with DroneCAN/CAN sensors and richer sensor integration.


The additions that would make it especially useful for small drone installs would be mostly connector/debug/power convenience items: JST-SH 1.0 mm CAN connector option for compact FC harnesses, maybe a JST-GH variant for Pixhawk/DroneCAN users, CAN in/out pass-through connectors, selectable 120R termination, PWR/TX/RX LEDs, and possibly a simple optional 5V BEC or 5V injection jumper for powering small CAN sensors from the board.

 

[jlaustill]

This is a great perspective, something totally different than what I’ve done so far but have dreamed about doing someday, drones

The direction I'm leaning is keeping the module itself as tiny as possible — just the rugged CAN node — and push everything install-specific (connectors, LEDs, power, termination) onto the carrier board it solders onto.

It comes down to cost, complexity, reuse, and flexibility for me. I want to use these in many different applications, automotive ECU’s, bench testers, home automation projects, and now hopefully a drone someday haha.

Anything baked into the core gets paid for, assembled, and carried by every build, even the ones that don't use it. Keeping the core module minimal, each build adds only what it needs, the module stays cheap and reusable across wildly different projects, and the castellated edges let carriers stack (ESP32-style) to mix power + CAN + I/O without one bloated board.

Maybe I’m being too optimistic, but that is how I’m approaching this module.

 

[OIEIEIO]

That makes a lot of sense.

That carrier-board split is exactly why I’m interested from the drone side.

We’ve been building Snow Owl as an embedded companion layer for ArduPilot-style drones: MAVLink (drone sensors info) telemetry in, local odometry / sensor state, lightweight Rust MLP policy inference, and shadow-mode comparison before any control injection.

The screenshot is the current shadow dashboard. It was designed with Teensy-class embedded hardware in mind, so a rugged CAN FD node plus drone-specific carrier board is very relevant to where this could go.

Also worth noting: my drone frames are essentially 100% carbon fiber, so I would not assume the airframe is a valid ground reference.

 

[jlaustill]

Does your drone have a project page or anything? You have really peaked my interest.

 

[OIEIEIO]

The drone itself does not have a project page yet. I do have a splash page up for my drone work - its basic - I run R&D
--https://arc.oieieio.ca/--


Here is my current Teensy 4.1 trainer

Runs a MicoAir (stmH743) flight stack with a Teensy 4.1 connected to uart 5 on the flight controller.
Teensy uses MAVlink to monitor and injection to send commands to flight controller.
--https://mavlink.io/en/--

ArduPilot + Snow Owl (on Teensy)
--https://ardupilot.org/--

Bench shadow dashboard running live.

ArduPilot is flying the normal stack, while Snow Owl is watching MAVLink telemetry, building its own local flow/range odometry, running a trained MLP policy, and comparing the neural-net output against a safe teacher policy.

Important part: injection is disabled.

So this is not controlling the drone yet — it is learning, logging, and proving that the trained policy can track the safe controller in real time before it ever gets authority.

Basically:

ArduPilot alone: standard flight controller stack.
ArduPilot + Snow Owl(Teensy): standard flight controller stack plus an external AI shadow brain watching, learning, comparing, and preparing for supervised autonomy.


Small frame uses 10" propellers - large frames use 17" propellers.

CANbus (aka DroneCAN in the drone world) for the bigger frame
--https://dronecan.github.io/--