hardware

timestamp, ACK와 ACK error

hsl7 2025. 6. 11. 12:09

시작하기 전에 

CAN 프레임에는 ACK 비트가 있다.

CAN 프레임 구조. 출처: 페스카로. https://www.fescaro.com/ko/archives/249/

 

CAN 하드웨어 설정에는 Controller Mode 항목이 있고, 이 항목에는 "ACK Off"라는 옵션이 있다. 

CAN Controller Mode에는 ACK Off라는 옵션이 있다.

 

ACK 관련하여 ACK error가 발생하기도 한다. ACK 관련하여 실험한 내용을 정리한다.

 

 

개요

  • 실험 환경
  • ACK와 timestamp
  • ACK Off와 ACK error
  • ACK Off를 사용하는 경우
  • 결론

 

 

실험 환경

  • CAN 채널이 2개인 TC1013을 이용한다.
  • TC1013의 두 채널을 아래 사진처럼 점퍼 케이블로 연결한다. 

 

 

  • TSMaster에서  메시지를 송신할 Transmit 창과 수신 메시지를 표시할 Trace 창을 연다
  • 채널 1에서 메시지를 전송하고 채널 2에서 수신한다.

 

 

 

ACK와 timestamp

  • 채널 1과 2의 하드웨어 설정을 디폴트로 하였다. 디폴트의 Controller Mode는 Normal이다. Normal 설정에서, 수신 제어기는 메시지를 수신하면 ACK 신호를 전송한다. 

채널 1과 채널 2의 하드웨어 설정을 동일하게 하였다. Controller Mode는 양쪽 모두 Normal이다.

  • Transmit 창에서 메시지 추가 버튼을 클릭하여 아이디가 0x123인 메시지를 만들었다.

Transmit 창에서 메시지 추가 버튼을 클릭하여 아이디가 0x123인 메시지를 정의한다.

  • Start 버튼을 클릭하여 CAN 통신 모니터링을 시작한다.

  • Transmit 창에서 Send 버튼을 클릭하여 0x123 메시지를 전송한다. (그리고 위 그림의 Stop 버튼을 클릭하여 모니터링을 종료한다.)

  • Trace 창을 보면 채널 1에서 송신한 메시지가 채널 2에서 수신된 것을 볼 수 있다. 여기까지는 별다른 점이 없다.
  • 타임스탬프를 보면 채널 2의 타임스탬프(1.996617)가 채널 1의 타임스탬프(1.996617)보다 (2usec)더 앞선다. 타임스탬프만 보자면 메시지가 수신된 후에 송신이 된 셈이다??? 

timestamp를 보면 수신 시각이 송신 시각보다 앞선다. 수신 후 송신이 이뤄진 것인가?

  • 이는 CAN 프레임의 구조와 ACK 신호와 관련이 있다. CAN 프레임에는 ACK 비트가 있다. 아래 그림의 빨간색 박스친 부분이다.

  • ACK 신호는 송신 제어기가 아닌 수신 제어기가 보낸 신호이다. (당연하다. ACK는 메시지를 받았다는 의미이니까.) 그래서 ACK 비트 앞뒤로 DELiminator 비트가 각각 있다. 우리 말로 간극이라고 하는 것이 맞을 것 같다. 송신 제어기가 SOF부터  CRC sequence까지 전송한 후에 간극을 갖고 기다리면, 수신 제어기가(제어기들이) ACK 신호를 전송한다. 송신 제어기는 ACK 신호를 확인한 후에 프레임의 나머지 부분인 EOF 부분을 전송한다.
  • 수신 제어기의 타임스탬프는 ACK를 전송한 시점이고, 송신 제어기의 타임스탬프는 EOF까지 전송을 마친 시점이다.

 

ACK Off와 Ack error

  • 수신 측인 채널 2의 Controller Mode를 Normal에서 ACK Off로 변경하고 동일한 실험을 해본다. 

수신측인 CAN2 채널만 Controller Mode를 ACK Off로 변경한다.

  • Trace 창을 보면 갑자기 메시지들이 넘치게 많이 표시된다. 아래 그림과 같다. 채널2를 ACK Off 로 설정하니, 채널1에 ACK error 발생한다. (당연하다. ACK 신호를 못 받았으니까.)  ACK error가 발생하니, 채널 1은 재전송을 시도한다. (당연하다. 프레임이 전달되지 않았다고 생각하니까.) 역시 ACK 신호를 받지 못하니까 다시 ACK error가 발생한다. 이를 계속 반복하기에 Trace 창이 채널 1의 재전송 메시지와 ACK error로 넘친다. 

채널2을 ACK Off로 설정하니 채널1에 ACK error 발생한다. ACK error가 발생하니, 채널1은 재전송을 시도한다. ACK error가 반복된다. 재전송이 반복된다.

  • 채널 2는 ACK Off를 했지만 채널 1이 전송한 0x123 메시지를 잘 수신한다. 재전송 메시지들도 잘 수신한다. 반면에 채널 1은 메시지가 전송되지 않았다고 메시지를 무한 재송신한다. 버스 로드가 89.92%까지 올라간다. 초당 프레임수가 3,597개나 된다. 메시지 전송 주기로 환산하면 0.278msec이다. 이렇게 되면 다른 제어기들의 통신에 크게 방해가 된다. CAN 통신이 제대로 될 수 없다.

 

ACK Off를 사용하는 경우

  • 아래 그림처럼 CAN 버스를 모니터링 목적으로 CAN 측정 장치를 버스에 추가할 경우, 측정 장치가 제어기들 사이의 CAN 통신을 방해하지 않도록 해야한다. CAN 측정 장치가 ACK 신호를 송신하면, 실제 ACK error가 발생해야 하는 경우 그렇지 않게 될 수 있다. 이런 경우에 CAN 측정 장치는 Controller Mode를 ACK Off로 한다.

  • 제어기와 CAN 측정 장치 둘만 연결하는 경우, CAN 측정 장치를 ACK Off로 설정하면 제어기는 ACK error를 감지하여 정상적인 실험을 할 수 없다. 이럴 경우, CAN 측정 장치의 Controller Mode를 Normal로 설정한다. 

 

 

결론

  • CAN 프레임의 ACK 신호와 타임스탬프와 ACK error 사이의 관계를 설명하였다.
  • 시험 환경과 목적에 따라 CAN Controller의 모드를 적절하게 설정해야 한다. 

 

목차 :: hsl's tsmaster 사용기