Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Keep the CAN logger lossless alongside BLE and report its stats

Open
  • Is something wrong?
#55 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
embedded-iot, networking, observability

Research direction

Start with #44 and #51 to understand the CAN logger channel and the SystemState changes, then read docs/can.md and docs/ble.md. The issue lists measurements and desired stats, but the firmware source files and tests are not named; locate the session write path, BLE command handling, and DHCP completion handler. Done means the logger reports drops, throughput, high-water mark and blocked-write time, handles BLE activity as specified, logs the station IP, and the docs are updated.

Written by the indexing model from the issue text.

Description

enhancement

Part of #10. Builds on #22 (PR #44) and coordinates with #51, which adds the logger toggle and SystemState fields.

What we measured

On an EV6 (one bus, ~2150 frames/s at the OBD port), WiCAN on a phone hotspot, laptop on the same hotspot:

Setup Frames lost
2 KB TCP send buffer, 64-frame CAN_LOG_CHANNEL (first version of #44) ~75%, in gaps of up to 300 ms
16 KB send buffer, 256-frame channel, no BLE connection 0 in 30 s
Same, app connected over BLE, MQTT retrying 222 of ~64,700 (0.3%), in one ~100 ms burst

TWAI reported 0 overruns throughout, so the losses are all on the logging path. With 16 KB the average throughput has ~4× headroom. Stalls are the limit: the laptop saw reads stall for up to ~400 ms, and the send buffer plus the channel only hold ~0.5 s of frames. On the ESP32-C3, WiFi and BLE share one radio, so an active BLE connection takes airtime from WiFi and lengthens those stalls.

We couldn't tell whether the 222-frame burst came from the TCP buffer being full or from the logger task not being polled for ~100 ms. Only the serial log showed the drop count.

To do

  • See the margin, not just the drops. Track the channel's high-water mark and the longest time the session spent blocked in a write, and log them with the drop count when the session ends. Add frames/s and drops to the logger state that #51 puts in SystemState, so the app can show them (contracts change, append-only).
  • Log the WiFi station IP when DHCP completes (WiFi: got IP …). With the logger enabled from config.toml, there's currently no way to find the address short of scanning the network.
  • Keep BLE quiet during a session. While SavvyCAN is connected:
    • request a long BLE connection interval (e.g. 100–500 ms) and restore it at the end
    • only publish the logger state and stats; the vehicle is idle anyway
    • accept the command that turns the logger off; reject other commands with a clear status
  • Re-measure on the car with the app connected, using the high-water mark. Then decide whether a bigger send buffer (32 KB; RAM allows it on the C3) or a bigger channel is still needed.
  • Update docs/can.md and docs/ble.md.

Considered

Suspending the MQTT task while logging. The vehicle publishes almost nothing then, and the 0-drop runs had MQTT retrying in the background, so it's unlikely to matter. Revisit only if the measurements point at it.

Dominant language
Rust
Stars
1
Forks
0
Avg merge
13h 37m
Merged PRs (30d)
8

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenCarControls/firmware

All issues in OpenCarControls/firmware

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.