We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(i'm surprised nobody else has reported this)
The telelogger (v5) transmits uint64 for timestamps from CPU ticks
telelogger
Freematics/firmware_v5/telelogger/teleclient.cpp
Line 161 in 98f38d9
teleserver
atol()
Freematics/server/teleserver/teleserver.h
Line 87 in 98f38d9
Freematics/server/teleserver/udpserver.c
Line 115 in 98f38d9
Lines 129 to 131 in 98f38d9
Indeed we have noticed that device-ticks overflow at random durations, roughly before ~20 days (31bits correspond to ~25days, 32-->49days).
Q1: is this analysis correct? Q2: (if yes) is this on purpose? Q3: (if no) would you accept a PR to fix it?
The text was updated successfully, but these errors were encountered:
No branches or pull requests
(i'm surprised nobody else has reported this)
The
telelogger
(v5) transmits uint64 for timestamps from CPU ticksFreematics/firmware_v5/telelogger/teleclient.cpp
Line 161 in 98f38d9
but
teleserver
although it usesatol()
to parse it back, it assigns the result in a uint32(!):Freematics/server/teleserver/teleserver.h
Line 87 in 98f38d9
Freematics/server/teleserver/udpserver.c
Line 115 in 98f38d9
Freematics/server/teleserver/udpserver.c
Lines 129 to 131 in 98f38d9
Indeed we have noticed that device-ticks overflow at random durations, roughly before ~20 days (31bits correspond to ~25days, 32-->49days).
Q1: is this analysis correct?
Q2: (if yes) is this on purpose?
Q3: (if no) would you accept a PR to fix it?
The text was updated successfully, but these errors were encountered: