Transmitting Time and Date on CAN

Connectivity RealDash CAN
1

I’d like to transmit the device time and date on CAN. I can get time as seconds since midnight which is good, but I cant get a date.

XML for time -

...
       <frame id="0x129" endianess="big" writeInterval="1000">
           <value targetId="210" offset="0" length="4"></value>
...

ID 210 being the Time (local) signal.
If I change 210 to 211 which is the Date signal, I just get the same time in seconds since midnight.

I tried Time (ISO 8601) also, but the same result.

I’d be happy with date in any format, separate day, month, year values or Days since some date, but unix time would be ideal. Are any of these possible? Is there perhaps a unit=“date” type thing I can specify in the xml to get the date?

Thanks,
Darren.

2

I think sending date over CAN is not supported at the moment. RealDash stores the date in text form, and its numerical value is probably not set correctly. I will check this if I can do something about this.

3

Thanks, that would be great!

4

Next update will have the date value in Epoch.

5

Awesome!

6

I tried the new version, transmitted Date on CAN and I get unix time! Really great support, I’m starting to get the hang of RealDash and so far it’s doing all the crazy stuff I want to do so that is impressive!

But just so you know the time is rounded to 128s due to floating point precision. I can deal with that using the Time signal as well, but if you can fix that too it might help others.

7

I have a solution in RealDash for the floating point resolution issue.

        <frame id="0x10" writeInterval="1000">
           <value targetId="210" startbit="0" bitcount="7" conversionOut="V+31"></value>
           <value targetId="211" startbit="7" bitcount="25" conversionOut="V/128"></value>

This makes the full 32bit unix time with 1s resolution. The first 7 bits (0 - 127s) is using the Time channel. The V+31 just lines up the seconds to roll over with when the Date increments each 128s. The Date value is div by 128 so it increments by 1 each 128s and starts at bit 7 of the frame. The two go together.

It’s just by pure luck that 128 is a factor of 86400, so when the Time rolls over for the day it should still give me the right value. And the Date will keep it’s 128s resolution until 19th Jan 2038! :slight_smile:

But I assume I’ll have to adjust the +31 offset when daylight saving comes around. And anyone using this will also need to adjust the offset for different time zones.

1 Like
8

I was thinking of using different format due the precision problems but though that changing the date is not such important to be precise. We must come back to this 2038 the latest :smiley: