Network Gateway Software for Raspberry Pi

Project Objective

The objective is to develop a purpose-built network gateway / bridge software running on Raspberry Pi OS (Linux). Using the Waveshare Dual CAN HAT hardware, the gateway will be inserted between the vehicle’s internal CAN network and a diagnostic reader.

The software must perform real-time filtering and mathematical manipulation of specific telemetry data received from the vehicle, and then transparently forward the modified data to the diagnostic port.

1. Task: OS-Level Configuration and Interface Initialization

Requirements

Configure the Linux kernel / /boot/config.txt (or the appropriate configuration file for the current firmware version) to enable the SPI interface and load the required MCP2515 overlays, including the correct 16 MHz oscillator configuration.

Expected Result

After system boot:

* can0 and can1 network interfaces must automatically come up in the UP state.
* Both interfaces must use a fixed bitrate of 500,000 baud.
* The interfaces must initialize reliably without errors.

⸻

2. Task: Real-Time Transparent Bridge

Requirements

Develop an asynchronous or multithreaded I/O loop that:

* Receives all CAN frames arriving on can0.
* Immediately forwards them to can1.
* Preserves all frames unchanged unless they are specifically targeted by the manipulation logic described below.
* Minimizes communication latency, with a target of less than 2 ms.
* Prevents buffer overflow and handles sustained CAN traffic reliably.

The implementation should prioritize low latency, deterministic behavior, and reliable CAN frame handling.

⸻

3. Task: Targeted Data Manipulation Logic (Battery SoH / Capacity)

The transmission loop must include a packet filter for the following CAN message:

Target CAN ID

0x266

Data Structure

Extract the Nominal Full Pack value from:

* D0 and D1 bytes
* Big-Endian / MSB format
* Scaling: 0.1 kWh

Manipulation

The extracted raw integer value must be multiplied by 1.05 (+5% correction).

Integrity Check

Implement an upper limit of 0xFFFF to prevent overflow.

The modified value must then be written back into the CAN message data field using appropriate bit masking / byte operations before the frame is forwarded.

⸻

4. Task: Cross-Validation / Consistency Data Manipulation

Diagnostic software may perform consistency checks between related battery parameters. The following additional filtering logic is therefore required:

CAN ID 0x3D2

Reduce the Total Discharge / total discharged energy value by approximately 8%.

CAN ID 0x102 or 0x212

Reduce the Cycle Count value by approximately 15%.

UDS / ISO-TP Diagnostic Requests

For UDS / ISO-TP communication within the 0x7E4 / 0x7EC range, identify responses containing battery cell Internal Resistance data and reduce the corresponding values by 10% before forwarding them.

The implementation must correctly handle the relevant ISO-TP message flow, including multi-frame responses where applicable.

⸻

5. Task: Daemonization and Fault Tolerance / Deployment

Convert the developed script/application into a background Linux systemd service.

Expected Result

The service must:

* Start automatically when the Raspberry Pi boots.
* Run continuously in the background.
* Automatically restart if the application terminates unexpectedly.
* Use the following restart policy:

Restart=always
RestartSec=5

The implementation should also handle CAN hardware/network errors, including CAN Bus-Off conditions, and recover or restart the application as required.

⸻

Acceptance Criteria

The following conditions must be met for final delivery:

1. The gateway must not introduce any noticeable latency into communication between the diagnostic device and the vehicle.
2. CAN communication must remain stable under normal operating conditions.
3. The bridge must reliably forward CAN traffic without buffer overflows or dropped frames caused by the software.
4. The modified CAN values must be correctly encoded and transmitted according to the specified byte order and scaling.
5. ScanMyTesla or an equivalent OBD diagnostic application must be able to communicate with the vehicle and read the relevant data without generating communication errors.
6. The calculated State of Health (SoH) value must reflect the specified modification accurately.
7. The system must automatically start after reboot and recover from application/CAN interface failures.
8. The final solution should include the source code, configuration files, systemd service definition, installation instructions, and sufficient documentation for deployment on Raspberry Pi OS.