Sync Jump Width (SJW) in Controller Area Network

[vini_i]

Is there any drawback to a longer SJW vs a shorter SJW?

The PIC32MZ2048EFH064 has a minimum phase 2 requirement of two time-quanta. This means that the SJW could be one or two time-quanta. Why wouldn't an SJW of two not be used by default?

Similarly, if phase 2 is eight time-quanta why not use an SJW of four?

[SparkyFX]

I guess that these considerations are more about the (expected/measured) jitter and drift between clocks of all nodes on the network than about a single node. You can´t do much about the jitter, but you want to compensate drift.

[vini_i]

I guess I should clarify more.

The assumption is that a connection is made to an unknown bus with a known baud rate. The best I've been able to find is an app note from analog devices. They state that the sampling point should be pushed back as far as possible in the bit to compensate for the worst possible propagation delay. This makes sense because even if the bus was really short and the propagation delay was small there is no penalty for sampling late. Whereas if the bus had lots of delay and the sampling point was early this could cause problems.

On the other hand, I can't find any such recommendations for the SJW. Reasoning through it, seemingly the greatest SJW would be best. This would compensate for the greatest drift/jitter. If this is accurate then why is the SJW not just the width of phase 2 but no more than four?

[NorthGuy]

... there is no penalty for sampling late.

Certainly there is. If you sample too late, the transmitter may be already moving to the next bit.

On the other hand, I can't find any such recommendations for the SJW. Reasoning through it, seemingly the greatest SJW would be best. This would compensate for the greatest drift/jitter. If this is accurate then why is the SJW not just the width of phase 2 but no more than four?

I always had two phases equal and the jump set to maximum value (either phase2 or 4). I think 4 is the hardware limit - the controller cannot do more. I had problems with bad clock once (I used the internal oscillator and the frequency was slightly off). I tried to help the problem by tweaking these parameters, but nothing really helped until I added code for the oscillator calibration.

[vini_i]

Certainly there is. If you sample too late, the transmitter may be already moving to the next bit.

In the case that Phase2 is two time quanta then there is a severe timing deficiency if the trailing bit edge comes too soon. I would be connecting to an already existing and functioning network (but of unknown length).

I always had two phases equal and the jump set to maximum value (either phase2 or 4). I think 4 is the hardware limit - the controller cannot do more. I had problems with bad clock once (I used the internal oscillator and the frequency was slightly off). I tried to help the problem by tweaking these parameters, but nothing really helped until I added code for the oscillator calibration.

The crystal on the board is suited for High Speed USB application making it far more accurate than CAN could ever need.

[Siwastaja]

Years ago, I googled quite a bit into the timing requirements of the CAN bus, and actual experience gained by the others. After all, sometimes looking at the issues faced by others is far quicker than making all the mistakes yourself. My outcome, and my advice to myself I ended up with is:

While the CAN bus is specified to work with fairly high clock rate error (don't remember the exact figure, around +/-1%?), I found several academic and practical studies proving that the bus design doesn't work reliably with clock errors nearly outside (but still within) the spec, and thus, recommend adding extra margin for the allowed clock rate error. I.e., people who trusted the advertised "robustness" and used inaccurate clock sources, were fucked.

While CAN bus can definitely be made to work with RC oscillators, if I'm not wrong, CAN is mostly used to provide robustness in medium- and high-cost systems - not lowest cost, nor lowest power.

Robustness is a complex issue, and because not everyone has equipment and time to perform exhaustive analysis over selected parameters, in my opinion, a system that requires fine-tuning parameters to compensate for inaccurate clock source, to work reliably, will be inherently less robust. If adjusting the parameters is critical for the system to work, this means there is little margin for error left, possibly even with the "optimized" settings. With an RC oscillator, everything should be measured over full operating conditions (temperature, voltage, unit-to-unit differences)...

Hence, my end result was: if I choose to use CAN, I always use a proper crystal oscillator to clock the CAN devices. Sure, this gives 10-100x less worst-case clock error than what would be "allowed" by the CAN specification, but this also makes fine-tuning timing parameters less critical, and saves a lot of my time. For the BOM, this is of course a $0.10 increase.

What I found is that with a typical low-cost crystal source, the situation is indeed "far more accurate than CAN could ever need" - and the setting for SJW is irrelevant, 1 is enough.