Hi Pavel, On 09/23/2011 11:32 AM, Pavel Pisa wrote: > Hello Oliver and Wolfgang, > > On Friday 23 September 2011 09:24:20 Wolfgang Grandegger wrote: >> Hi Oliver, >> >> On 09/22/2011 09:41 PM, Oliver Hartkopp wrote: >> Then let us set it to 4 (maximum), by default. But other documents >> recommend a value of 1. > > I am not expert for CAN timing nor I have time to go through > documentation at this moment. But I hope that I have some > sense/experience for electronic and dynamic systems > and we have done more designs utilizing CAN at university > and at our company. > > So there are some thought about SJW based on my experience. > There could be some inaccuracies, if you want better > analysis, I need time for that. > > 1) The CAN needs fast local roundrip time for correct operation > of dominant/recessive arbitration. > The time is sum of propagation from CAN controller chip, > propagation delay of optocoupler or other galvanic isolation, > slew rate and delay in Tx circuitry of transceiver, charging > the wire, Rx part of receiver, optocoupler, controller > Rx filtering and Rx,Tx logic level comparator. > Iw we count necessity to synchronize this between multiple > CAN nodes then whole roundtrip time has to be smaller than > 50-80% of single bit bit time quantum. > > 2) From the noise and stabilization of voltage on the wire > the sampling point should be in the middle of bit pulse > delayed by round-trip delay from 1. This is 50% of bit > time (i.e. dependent on bitrate) + round trip delay (dependent > on delay in controller and concrete board circuitry). > > 3) But sampling point has to allow to decide about collision > before next bit Tx is started => it cannot be moved after > end of the given Tx bit time interval. > > 4) It is necessary to synchronize bit timing in all > CAN controllers during arbitration (ID sending) phase. > The first sync is done after receiving of the first > edge on the wire. It can be other node start of Tx > or our own Tx dominant level. Controller shifts its Tx > timing such way, that start of the next Tx bit interval > should result in Rx transition at the end the sensed > Rx bit. I.e. it counts only TSEG2 til next bit start. > > 5) There are some more things to consider if triple > sampling and filtering is enabled to suppress noise > on wire. It can be used only, if time quantum clocks > are fast enough to fit this sampling interval between > stabilization of delayed Rx logic level and end of Tx bit > time interval. > > 6) If the clock frequencies of all nodes CAN controllers > are guaranteed to be same, then no more synchronization > is necessary during message Tx/Rx (SJW=0). But that assumption > does not hold. That is why bitstuffing is used and guarantees > that there is at least one logic level transition (edge) > after each 6 bit time. If there is zero roundtrip propagation > delay and sampling in 50% of bit time interval then > maximal skew/frequency difference of the clocks could be > > (1+1/6*50%) - 1 i.e. 8% > > This means, that SJW bigger than 8% of whole bit time > would not help to synchronize bitrate difference, because > for such case setup cannot work anyway. Propagation delay > is not zero then there is even less time left for sampling > point shift which would not cause incorrect bit data > detection so reasonable maximum is probably lower. > > I expect that for reasonable precise setup of bitrate > when exact ratio is found and crystal based oscillators > there is the best option small SJW i.e. 1 or for very > fast TQ clock equivalent of 1% - 2% of bittime. > For nonexact ratio or low quality clocks sources, > bigger SJW values make sense. But big value has other > disadvantage. If there is bigger jitter in Tx/Rx delays > or clocks then it is propagated back to bit timing > and stability of system composed from multiple nodes > could be questionable. There is even bigger interval > where noise pulse could cause lost of the synchronization. > > On base of above analysis, I think that blindly set SJW > on maximum is not good idea. It should be at least limited > to 5% of bit time. > > Because bit timing calculation is not what everybody > want to do again and again, the actual code tries > to hide differences of CAN controllers and provide > at least partially understandable knobs to user > with parameters independent on concrete setup low level > details to allow set bitrate for usual Joe user. > The basic parameters are chosen such way, that user need > not to care about actual TQ clock and selecting prescaller, > that is why sampling point is in percent of bittime. > SJW is more problematic, but may it be use of 2 or 5% > of bittime by default with assurance that zero is > replaced by one, would serve to most people pleasure. > May it be, that 0.1 of percent should be used as unit > for external parameter too. > > I hope that actual calculation works reasonably well. > But if it should be enhanced, then it would worth > to add additional parameter except crystal/controller > clock source freqency to the concrete boards drivers. > It should be measured round-trip delay of given/used > transceiver/optocouplers combination. This would > allow to have sampling point setup yet more independent > on given HW and same value could be used for different > bitrates. But there is still unknown parameter > capacity/length of connected wires so there is still > something left to user consideration.
Thanks for your detailed explanation. It clearly shows that adjusting SJW is non-trivial and nothing a normal CAN user should deal with. When adjusting SJW, do you also need to tweek other bit-timing parameters, e.g. tq? I mean, would "ip link set can0 type can bitrate x sampling-point y sjw z" work for your setup or do you need to use the expert mode setting via "ip link set can0 type can tq ..." anyway? Wolfgang. _______________________________________________ Socketcan-core mailing list Socketcan-core@lists.berlios.de https://lists.berlios.de/mailman/listinfo/socketcan-core
