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

Timestamp when message is transmitted

Abierto
#2,029 2 comentarios 0 reacciones 0 asignados Ver en GitHub

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
Estancado
Stack tecnológico
python
Área
embedded-iot, networking

Línea de trabajo

Comienza rastreando el ciclo de vida de bus.send y Message.timestamp a través de las implementaciones de los controladores CAN. Compara cuándo se confirma la transmisión con la marca de tiempo que actualmente se expone a los llamadores. La tarea estará terminada cuando los controladores compatibles proporcionen la marca de tiempo real de transmisión sin informarla antes de que el mensaje se envíe físicamente, y el comportamiento esté aclarado para los controladores que no puedan proporcionar una.

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

Descripción

enhancement
Is your feature request related to a problem? Please describe.

I would like to measure the time it takes for a CAN node to respond to a given message.
Received messages have their timestamp correctly set, however there is no direct way to get the timestamp when a message is transmitted.

As a workaround, I'm using the timestamp when I call bus.send, however this is not necessarily the time when the message is actually transmitted on the bus (up to 30 ms difference).
The timings I'm measuring with this workaround do not match the timings I'm directly recording in the PCAN software.

Describe the solution you'd like

Ideally, the bus.send implementation would override the .timestamp property of the message object I called it with.
By default, the timestamp is 0.0 on newly constructed messages. Calling bus.sent does not immediately cause a transmission but only puts the message into the transmit buffer of the can device. For best results, the can driver implementation should set the correct timestamp once message was actually sent.

msg = can.Message(...)
print(msg.timestamp) # 0.0 - default
bus.send(msg)
print(msg.timestamp) # 0.0 - message given to can device but not physically sent yet
time.sleep(0.5)
print(msg.timestamp) # 1773217081.775475 - can driver sets timestamp property once message was actually transmitted
Describe alternatives you've considered

I have considered setting up a virtual can or configuring some loopback setup, such that i can use the receive timestamps for both received & transmitted messages. However this seems rather complicated for a seemingly simple task.

Lenguaje dominante
Python
Estrellas
1.6k
Forks
697
Sin PR fusionados en 30 d

Guía de contribución

Abrir la 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 hardbyte/python-can

Todos los issues de hardbyte/python-can

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.