Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Keep the CAN logger lossless alongside BLE and report its stats

Aperta
  • Qualcosa non va?
#55 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
embedded-iot, networking, observability

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Rust
Stelle
1
Fork
0
Merge medio
13h 37m
PR unite (30g)
8

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Nessun Dockerfile né file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OpenCarControls/firmware

Tutte le issue di OpenCarControls/firmware

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.