5
\$\begingroup\$

I'm trying to receive CAN messages from a radar, whose specification define the following data for bit timing:

CAN baudrate = 250 kBaud
Tseg1 = 8
Tseg2 = 7
Tsjw  = 4
Synchronization on one edge only.

I'm using a 16 MHz crystal in the classic MCP2515 (CAN Controller) + MCP2551 (CAN Transceiver) setup, which I use between the CAN bus and an Arduino Uno, but I believe I'm having some trouble when setting the bit timing configuration in the MCP2515.

This is because using a 16 MHz clock frequency limits the Time Quanta per bit time to be 16. I'm using the MBtime tool to verify the bit timing.

     1 time quanta synchronization segment
   + 1 time quanta propagation delay
   + 8 time quanta phase segment 1
   + 7 time quanta phase segment 2
 ----------------------------
  = 17 time quanta

Which is one more than the required one (16). Being the sync segment is always one, and the propagation segment at least one, how is it possible to make it work with the required parameters?

My ideas are using another crystal, maybe 18 or 20 MHz. (I actually tried with 20 MHz and a four time quanta propagation delay, and it didn't work.)

However, using a CAN-to-USB converter in my PC, I did successfully receive the CAN frames I was expecting from the radar. I set the same settings (Tseg1, Tseg2, SJW, and baud rate). And this converter uses a 16 MHz crystal...

Is there something I'm missing? Should I change the oscillator frequency to another value?

\$\endgroup\$
  • \$\begingroup\$ You should just be able to reduce phase segment 2 by 1. \$\endgroup\$ – Rocketmagnet Feb 20 '13 at 13:04
  • \$\begingroup\$ Why does the radar specify phase segment2 to be 7 then? I will try with PHS2=6, just in case. Thanks ;) \$\endgroup\$ – Daniel Feb 20 '13 at 13:11
  • \$\begingroup\$ The segment 1 and 2 numbers aren't that critical. The only thing they control is exactly when the sample is taken. On some systems, you don't even get to choose these numbers, you can just say something like: "sample at the 75% bit time". \$\endgroup\$ – Rocketmagnet Feb 20 '13 at 13:29
  • \$\begingroup\$ I see, so your suggestion is that maybe the bit timing is not the problem I have right? The curious thing is that I receive data when connected to the CAN bus (as a sniffer), but always the same nonsense message :S \$\endgroup\$ – Daniel Feb 20 '13 at 13:48
  • \$\begingroup\$ All you need to do with the bit timings is make sure they add up to 16, that's the critical thing. \$\endgroup\$ – Rocketmagnet Feb 20 '13 at 13:55
2
\$\begingroup\$

The other side can't tell you how many time quanta to use for various parts of the bit. It can only tell you the bit rate you must adhere to.

Pick a set of time quanta close to what they use but that still comes out to the specified bit rate, and all will be fine. Consider their time quanta "spec" as merely them telling you how their implementation works, not what you have to do.

|improve this answer|||||
\$\endgroup\$
  • \$\begingroup\$ Thank you for your answer! I'll try and see what happens. \$\endgroup\$ – Daniel Feb 21 '13 at 10:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.