Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Keep the CAN logger lossless alongside BLE and report its stats

Abierto
  • ¿Algo no está bien?
#55 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
embedded-iot, networking, observability

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
1
Forks
0
Merge medio
13 h 37 min
PR fusionados (30 d)
8

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

  • Sin Dockerfile ni archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de OpenCarControls/firmware

Todos los issues de OpenCarControls/firmware

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.