Tuning the token return timeout value

PI is exactly 3!

Nah, i'm kidding, but now that i have your attention read carefully these words: Tuning the return token timeout value is EXTREMELY important, since wrong timing can lead to bus collisions. This timeout must be larger than the maximum time a slave ever need to send back a token. You need to calculate it with care and must be larger than the time taken by the worst case.

Why it can cause collisions?

I'll give you an example. Assumption: token return timeout is 100ms.

Now we can analyze the things that happen:

• 0 ms -> master send a token to slave 1
• 1 ms -> slave 1 receive token and start compute something who will end after 150 ms, a value larger than the return token timeout.
• 100 ms -> Master go in timeout because he didn't received back the token and it suppose the client is crashed. Since a bad client can't lock all the communication, he build up a new token and send it to the next slave.
• 101 ms -> Slave 2 receive the token, start compute something and finish it after 50ms.
• 151 ms -> Slave 2 send the response and the token back to the master BUT look, now 150 ms have passed since slave 1 started compute something and because now it have finished, also slave 1 tries to send back response and token to the slave

BAM! Now we have a collision. That's why you must be aware of the maximum time token by your slaves and set the timeout accordingly to this value.

Example

I need to communicate with a device who use a DS18b20 probe to get room temperature. From datasheed, ds18b20 can use up to 100 ms to return a temperature read at a specified resolution level. Assuming that the message is sent to the slave exactly in the same instant he start a temperature read, he is busy for up to 100 ms from the temperature read process. Then he can process the serial message and send back an optional response with the token. Our timeout will be 100ms plus a developer-discrection delay to compensate code execution and serial processing timing. let's estimate it to 40ms. Timeout will be 140ms.

Devices who do not send back token before going to timeout, are considered dead and reported as non-responsive.

If you cannot figure out the correct timeout, try this this poor engineered algorithm:

1. Make a very large timeout( one second or more)
2. Test on your project
3. If crc error count don't increase, try a smaller timeout and go to point 2
4. If a lot of crc errors start showing up, reset the timeout to a previous value (or increase it) and go to point 2
5. Continue until you get less crc error possible, remembering that sometimes a crc error can still occur, but for a transmission error, not for collisions.