
Every few years, a wave of products drops Bluetooth Classic support because BLE is newer, lower-power, and what every mobile SDK tutorial defaults to. This looks like a reasonable modernisation decision right up until it breaks every piece of existing diagnostic tooling that expects a serial port over Bluetooth SPP, and in industrial, marine, and agricultural settings, that tooling doesn't get replaced on the vendor's schedule.

## Two Populations of Devices That Never Fully Converge

Workshop diagnostic laptops running legacy software often expect Bluetooth Classic's Serial Port Profile (SPP), a virtual COM port that decades of Windows-based diagnostic tools were built around. That software isn't getting rewritten to talk BLE's GATT characteristic model just because a newer chip shipped. It works, it's validated, and replacing it has a cost that most workshops aren't going to absorb for a protocol change they didn't ask for.

Modern mobile apps, on the other hand, are built on BLE almost exclusively. iOS in particular restricts Classic Bluetooth SPP access for third-party apps at the platform level, a mobile companion app has no path to a serial port even if it wanted one. BLE isn't a choice for mobile-first tooling; it's the only option.

A product that has to serve both a workshop laptop with legacy diagnostic software and a technician's phone with a modern app cannot pick one transport and call it solved. It needs both, running at the same time, without the user choosing a mode.

## The Failure That Prompted This

Reliability reports across multiple Bluetooth-equipped charge controllers show the same pattern: BLE-only monitoring apps stop connecting after an Android OS update, most visibly around Android 13. The root cause varies, background scanning permission changes, BLE stack behaviour differences across OEM Android builds, connection-parameter negotiation edge cases, but the outcome is consistent: a device that worked yesterday stops pairing today, with no firmware change on the device side. The vendor's fix is usually an app update, which depends on every affected user finding and installing it, which doesn't happen uniformly across a fleet of field-deployed units.

A dual-mode device isn't immune to BLE-specific bugs, but it isn't single-point-of-failure dependent on BLE working correctly on every Android build in circulation. SPP remains available as a fallback path that doesn't share the same OS-level failure surface.

## What Dual-Mode Actually Requires

Running SPP and BLE simultaneously, not as a user-selectable mode, but concurrently on the same radio, is a firmware and RF design decision made early, not a checkbox in a chip's datasheet. The CC2564MODA, used across MicroCore's product line, supports genuine concurrent dual-mode operation: SPP for legacy workshop tools and serial-based diagnostic software, BLE for modern mobile apps, both active without a mode switch. Neither the [Marine Solar Charger](/products/marine-solar-charger)'s Bluetooth monitoring nor the [Wireless CAN Bridge](/products/wireless-can-bridge)'s diagnostic link makes a user pick a transport, both are live at once, because the alternative is deciding in advance which population of users gets left out.

The chip decision is only the starting point. Firmware has to manage two active Bluetooth stacks without one starving the other's connection window, and the RF layout has to account for both profiles operating concurrently rather than assuming only one radio mode is ever active. It's more firmware complexity than shipping BLE-only, and it's the difference between a device that works with the tooling a workshop already owns and one that quietly excludes it.

---

*MicroCore Systems, Auckland, NZ. Contact: jonathan@microcoresystems.co.nz*


Why Bluetooth Dual-Mode Matters More Than Bluetooth Version


CAN-FD gets pitched as backward compatible with classic CAN, and at the physical layer, that's mostly true, a CAN-FD controller can transmit and receive classic frames without issue. The problem isn't the physical layer. It's everything downstream of it, on a network where classic and CAN-FD nodes have to coexist during a migration that rarely happens all at once.

## Where "Backward Compatible" Stops Being True

A classic CAN controller cannot parse a CAN-FD frame. Not "parses it incorrectly", cannot parse it at all. If a CAN-FD node on a shared bus transmits an FD frame with the bit-rate switch (BRS) flag set, every classic-only node on that bus sees a frame that violates its expected format and raises a form error. Enough form errors and a classic node enters bus-off, taking itself off the network as a protection mechanism that was designed for a different failure scenario entirely.

This is the failure mode that doesn't show up in a two-node bench test. It shows up on a real vehicle or machine network with a dozen ECUs, some of which are years old and were never going to be replaced as part of the CAN-FD upgrade. The bench test passes. The field network doesn't.

## The Three Places This Actually Bites

**Data length code mismatch.** Classic CAN caps payload at 8 bytes. CAN-FD supports up to 64. A gateway or bridge device that receives a 64-byte CAN-FD frame and needs to relay meaningful data onto a classic segment has to make a decision about what to do with the other 56 bytes, truncate, multi-frame, or drop. Most off-the-shelf gateway firmware doesn't make this decision correctly by default; it has to be configured deliberately for the specific PGN or message set in use.

**Bit-rate switching on a bus that isn't tuned for it.** CAN-FD's BRS feature switches to a faster bit rate for the data phase of a frame. That faster bit rate has tighter tolerances for bus length, termination, and node loading than classic CAN's already-tight budget. A bus segment that was marginal but functional at classic CAN speeds can start showing intermittent errors the moment BRS is enabled, even though nothing else on the network changed. This is a signal-integrity problem wearing a protocol-migration costume, and it gets diagnosed as a software bug more often than it should.

**Silent gateways.** The most dangerous version of this failure isn't a hard bus-off, it's a gateway that silently drops CAN-FD frames it can't translate, with no error surfaced anywhere. The network looks healthy. The classic nodes report no errors. But whatever data was riding on the dropped frames, a sensor reading, a status flag, a diagnostic trouble code, simply never arrives, and nothing in the system says why.

## What an Actual Migration Plan Looks Like

The nodes that have to coexist during the transition period need to be mapped explicitly, which ECUs are staying classic CAN, which are moving to CAN-FD, and which are gateway or bridge points between the two. Every message that crosses that boundary needs its DLC and bit-rate handling defined, not assumed. And the physical bus, termination, stub lengths, node loading, needs to be re-validated against CAN-FD's tighter tolerances even on segments where nothing else is changing.

None of this is exotic engineering. It's the kind of protocol-level diagnostic work that catches a bus-off before it happens in the field rather than after a customer reports intermittent equipment faults that don't reproduce on the bench. The [MicroCore Wireless CAN Bridge](/products/wireless-can-bridge) was built with exactly this kind of mixed-network reality in mind, CAN-FD native, with automatic fallback to classic CAN at 250/500 kbps, so a diagnostic tool doesn't become another point of protocol mismatch on a network that's already mid-migration.

If a CAN-FD rollout is showing intermittent faults that don't reproduce consistently, the bus-off logs and DLC handling at the gateway are usually where the actual answer is, not the application layer where the symptom shows up.

---

*MicroCore Systems, Auckland, NZ. Contact: jonathan@microcoresystems.co.nz*


CAN-FD Migration: Where Backward Compatibility Actually Breaks

CAN Bus & Connectivity

J1939, NMEA 2000, ISOBUS, CAN-FD, and the wireless transports that carry them.

CAN bus is four protocols wearing one name. The physical layer is shared, but SAE J1939 on a truck, NMEA 2000 on a vessel, and ISOBUS (ISO 11783) on an agricultural implement each define their own application layer, address claiming, and message semantics. A tool that decodes one does not automatically decode another, and a network carrying mixed classic CAN and CAN-FD nodes has failure modes that a two-node bench test will never surface.

These notes cover protocol-level diagnostics and integration: where CAN-FD's backward compatibility actually breaks, how silent gateways drop frames without surfacing an error, why bus-off events trace back to signal integrity more often than to software, and what wireless transports (Bluetooth SPP, BLE, Wi-Fi) mean for field diagnostic access. Written for technicians and engineers working on heavy machinery, agricultural equipment, marine networks, and commercial vehicles.

Related hardware: the [MicroCore Wireless CAN Bridge](/products/wireless-can-bridge), a dual-mode Bluetooth to CAN-FD adapter with native J1939 and ISOBUS decoding.


CAN Bus & Connectivity Engineering

Why Bluetooth Dual-Mode Matters More Than Bluetooth Version

CAN-FD Migration: Where Backward Compatibility Actually Breaks