CAN BUS INFO

Some CAN transceivers timestamp their data -- you'd have to check yours to see if it does.

I assume you mean CAN controller and not transceiver? The transceiver is an analog part consisting of a differential line driver and receiver pair.

CAN frames don't inherently have a freshness bit or timestamp field, but it may be that the protocol you are running over the top of CAN does have this information. Do you know what protocol is being used?

For MSCAN and TouCAN modules, each message buffer has a timestamp field.

~Dave~

I think you're looking completely in the wrong direction. You expect a network protocol to carry semantics. That's not at all what a network protocol, like CAN, is about.

CAN doesn't care *at all* what the bytes in those messages mean. It's completely between the nodes on the network to invest meanings in those bits and bytes. There are pre-defined sets "standard meanings", e.g. the CanOpen framework. Some of them will have timestamps or age-of-reading information, others won't.

The general strategy should be "best effort", i.e. if a node sends something, it should always send the most current information. And it must be specified *somewhere* how old this most current information may be at maximum. This somewhere can be in the data sheet of the transmitting device, in some higher-level protocol requirement, in a self-description message of the device, which it sends out during an initial bus setup/discovery phase, or right there in the individual message.

In networks with more than one potentially active transmitting node, the transmission of any low priority message can be greatly delayed due to any messages from other nodes with higher priority (lower message-ID).

If accurate time information is needed, the event should be time stamped at the source and the time stamp and the event value should be transmitted in the same frame. In this way, the receiver can reconstruct when the event actually happened, even if the message delivery was delayed by several frame transmission times due to several high priority messages from other nodes.

Paul

Yes. And I forgot to ask why he can't just respond to interrupts from said controller and keep track that way.

I think he wants to know when the data was sent, not when it was received. On a high-traffic CAN bus, low-priority packets can (in theory) be delayed in the sending controller for a long time. AFAICT, he's trying to account for the latency incurred while the packet sits in the sending CAN controller waiting to be put on the wire.

If that's the case, a "received at" timestamp doesn't help any.

Hi Tim,

I like your idea of timestamping. But i have a very little knowledge about timestamping since it is not the part of CAN protocol. I guess may be my question was not completely understood. As i said transmitter does not send any information about the freshness of data or the time when the data is sent. My CONCERN is to make sure that i receive the data after every certian time and if do not see the data than i declare it stale. One of the idea that i had was to look at the interrupt and when i see interrupt happeing start a downward-counter. Now until the counter reaches to 0 if i see another interrupt happening than i have a new data other wise i would flag the data stale. Problem is that if i have 100 different messages how would i keep track of all thoes 100 messgaes (with different ID).

Thanks

Suffice it to say that if that ever becomes a realistic concern, somebody must have royally blown the message priority planning of his CAN bus. CAN has message priorities for the express purpose of avoiding this problem.

If a message can go stale (as in: too old to be useful) waiting in its outgoing message box, because other messages hogged the bus for too long, then the priority of those other messages relative to the one under study is clearly too high, or the CAN bus was loaded beyond its capabilities.

Unfortunately, this can easily open a whole new can of worms all by itself. CAN nodes don't routinely have real-time clocks.

I already pointed out that in this case, unless that transmitting node is seriously negligent in design and documentation, there still has to be *some* way of finding out how non-fresh those data will ever be. It'll say omewhere that this gadget will re-acquire actual data no longer than milliseconds than the previous one, and it will trigger a transmission of its message ever milliseconds. Find this information and use it. If you can't find it, sue the gadget's vendor and/or remove their junk from your designs.

It's impossible to say much about whether this is worth trying without knowing more about the traffic on your CAN bus: bit rate, message load, priorities, and such.

Not in a single timer, obviously. You'll need a receive-everything message box, 100 "receive slots " in main RAM, each with a time stamp stating "this data is until:", and static data that tell the interrupt handler how long this validity period, starting the moment it was received. Then you need an interrupt handler that stuffs the message in the appropriate slot, and updates the "best before:" stamp. And some other task will have to watch that list for stale data, continuously. It may be necessary to optimize that watcher task by a priority queue of which data will go stale next.

At least when using CanOpen, this is a practical problem, if the TxPDOs are triggered by the SYNC message from the master. In a large system with 64-127 nodes in the worst case you may have more than 100 TxPDO1 response frames after a SYNC request message, delaying any low priority message with hundreds of frame times if multiple TxPDOs are used.

Paul

But in this case, a SYNC protocol using CANopen network, the importand messages should be SYNCronized, synchrounous PDOS. And in this case its really clear, not the time of receiving or transmitting is importand but the time the data were sampled, and that is the time when all nodes saw the SYNC message. And SYNC can have a jitter, but thats known, it's typical the maximum length of CAN message.

Best regards Heinz

Still no buddy telling me what is time stamping? Is the recorded time when a message is received. If this is so ...... isn't it easy just to see that time and calculate down the time. (Obviously you have to know the data rate of the incomming message consider worst case senario) ??????

Well Tim, Interrupt just tell you that data is received they are not tied to message ID. What i am trying to say is that interrupt will tell you that there is a message but it won;t tell you what message

If my memory is correct, Freescale's MSCAN module has a two byte timestamp for both transmitted and received messages. I believe the transmitted message timestamp is updated on receipt of ACK. The module can be configured to zero this timer on receipt of a message into buffer 0.

I don't know if other manufacturers modules have this capability, but the OP did mention Freescale.

~Dave~

True -- you have to stay on top of the incoming messages.

Many CAN controllers have a register as part of each mailbox that gives you the local time that the message was received. As others have pointed out, this only tells you when the message was received -- not when it was transmitted.

If you need to be able to tell when a message was constructed, then you should put a timestamp in the message (or perhaps a sequence number). You'll still need a way to globally synchronize your devices on the bus, but you can do this with a special, short, high-priority sync message.

Un bel giorno Fizzy digitò:

I don't understand this need for hardware timestamping for CAN messages. We aren't talking about asynchronous capture inputs when even 100 nanoseconds latency is an issue. On a CAN bus you hardly will see more than 5000-10000 messages/s (and on a real-world CAN bus, not more than 1000 msg/s), therefore I think that the latency from the message entering the mailbox and the ISR that will process it is irrelevant. You just have to add the timestamp in the ISR, when you dispatch the message from the mailbox to wherever you want.