Timestamp when message is transmitted
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 35/100
- Issue-Typ
- Feature
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- python
- Bereich
- embedded-iot, networking
Rechercherichtung
Beginne damit, den Lebenszyklus von bus.send und Message.timestamp durch die CAN-Treiberimplementierungen zu verfolgen. Vergleiche, wann die Übertragung bestätigt wird, mit dem Zeitstempel, der den Aufrufern derzeit bereitgestellt wird. Abgeschlossen ist die Aufgabe, wenn unterstützte Treiber den tatsächlichen Übertragungszeitstempel bereitstellen, ohne ihn zu melden, bevor die Nachricht physisch gesendet wurde, und das Verhalten für Treiber, die keinen solchen Zeitstempel bereitstellen können, geklärt ist.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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.
- Vorherrschende Sprache
- Python
- Sterne
- 1.6k
- Forks
- 697
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus hardbyte/python-can
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
hardbyte/python-can#2103 ·
-
bug
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 78/100
hardbyte/python-can#2077 · 1 Kommentar · 1 Reaktion ·
-
bug
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 68/100
hardbyte/python-can#1922 · 1 Reaktion ·
-
enhancement
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 30/100
hardbyte/python-can#2102 ·
-
bug
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 68/100
hardbyte/python-can#2092 ·
Alle Issues in hardbyte/python-can
Ähnliche Issues
-
bug confirmed issue
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
open-webui/open-webui#30750 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
enhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
OpenwaterHealth/openmotion-bloodflow-app#604 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
-
good first issue
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100