공장 배전반에서 I2C 통신 센서값이 흔들릴 때
현장에서 먼저 의심할 것은 센서보다 버스 환경입니다
Q. 온도와 전류 센서값이 갑자기 튀면 센서 고장인가요?
인터뷰에 응한 임베디드 현장 엔지니어는 첫 답부터 단호했습니다. I2C 통신에서 값이 간헐적으로 튄다면 센서 자체보다 배선 길이, 접지, 풀업 저항, 전원 노이즈를 먼저 봐야 합니다. 특히 공장 배전반 안에서는 릴레이, 인버터, 모터 드라이버가 동시에 움직이기 때문에 책상 위에서 정상 동작하던 아두이노 회로도 현장에서는 전혀 다른 얼굴을 보입니다.
질문자는 라즈베리파이에 온습도 센서와 전류 센서를 묶어 설비 상태를 기록하고 있었습니다. 낮에는 정상인데 모터가 켜지는 순간 일부 값이 0으로 떨어지거나 이전 값이 반복 저장됐습니다. 이런 증상은 “센서가 가끔 멈춘다”로 보이지만, 실제로는 SDA와 SCL 라인이 노이즈를 받아 ACK 타이밍이 깨지는 경우가 많습니다.
- 증상이 랜덤하게 보이면 센서 불량보다 통신선 주변 환경을 먼저 확인합니다.
- 특정 장비가 켜질 때만 발생하면 전원 노이즈와 접지 루프 가능성이 커집니다.
- 긴 케이블에서만 실패하면 버스 커패시턴스와 풀업 저항 값이 핵심 변수입니다.
“I2C는 보드 내부나 짧은 모듈 연결에 강한 방식입니다. 배전반처럼 전기적으로 거친 공간에서는 통신 프로토콜보다 설치 조건이 더 큰 변수로 작동합니다.”
Q. 그럼 현장에서 가장 먼저 재현해야 할 조건은 무엇인가요?
전문가는 문제를 재현할 때 센서 하나만 보는 대신 설비 동작 시퀀스를 함께 기록하라고 조언했습니다. 예를 들어 모터 기동, 히터 온오프, 릴레이 전환, 통신 실패 시각을 같은 로그에 남기면 원인이 훨씬 빠르게 좁혀집니다. 라이프로그 서비스의 데이터 기록 개념처럼 시간 흐름에 따라 상태를 남기면 단순 오류가 패턴으로 바뀝니다.
케이블 길이와 풀업 저항은 숫자로 확인해야 합니다
Q. I2C 센서선을 1m 넘게 빼도 괜찮을까요?
전문가의 답은 “가능할 때도 있지만 기본값으로 믿으면 위험하다”였습니다. I2C 통신은 SDA와 SCL 두 라인을 오픈드레인 방식으로 끌어내리고, 풀업 저항이 다시 High 상태로 올려주는 구조입니다. 케이블이 길어지면 선 자체의 커패시턴스가 늘고 상승 시간이 느려져서 라즈베리파이나 마이크로컨트롤러가 High를 제대로 읽지 못할 수 있습니다.
실무에서는 10cm 점퍼선에서 잘 되던 센서가 80cm 케이블에서 불안정해지는 일이 흔합니다. 특히 여러 센서를 병렬로 묶으면 각 모듈에 이미 붙어 있는 풀업 저항이 합쳐져 전체 저항값이 낮아질 수도 있고, 반대로 긴 배선 때문에 신호가 느려질 수도 있습니다. 그래서 “4.7kΩ이면 된다” 같은 외운 값보다 오실로스코프로 상승 시간을 보는 습관이 더 중요합니다.
- 센서 1개만 연결해 기본 파형과 주소 인식 상태를 확인합니다.
- 케이블 길이를 실제 설치 길이로 맞춘 뒤 같은 코드를 실행합니다.
- 100kHz로 낮춘 뒤 안정화되는지 확인하고, 필요하면 풀업 값을 조정합니다.
- 센서를 하나씩 추가하며 어느 지점부터 실패율이 올라가는지 기록합니다.
Q. 풀업 저항은 무조건 낮추면 좋아지나요?
낮은 저항은 상승 시간을 빠르게 만들지만 전류 소모가 늘고, 장치가 Low로 끌어내릴 때 부담이 커집니다. 반대로 너무 높은 저항은 전류 부담은 줄지만 신호가 흐릿해집니다. 현장에서는 10kΩ, 4.7kΩ, 3.3kΩ, 2.2kΩ 정도를 후보로 두고 실제 센서 수와 케이블 조건에서 확인하는 방식이 현실적입니다.
- 짧은 보드 내부 연결: 4.7kΩ 전후가 무난한 출발점입니다.
- 센서가 여러 개인 버스: 모듈별 내장 풀업의 병렬 효과를 계산해야 합니다.
- 노이즈가 많은 배전반: 저항값 조정보다 케이블 배치와 차폐가 더 큰 효과를 낼 때가 많습니다.
아두이노와 라즈베리파이는 같은 I2C라도 대응법이 다릅니다
Q. 아두이노에서 되던 회로가 라즈베리파이에서 불안정한 이유는요?
아두이노와 라즈베리파이는 둘 다 입문자가 많이 쓰지만 전압 기준, 라이브러리 동작, 에러 처리 방식이 다릅니다. 아두이노의 기본 개념을 보면 교육용 보드로서 센서 실습에 적합한 생태계를 갖췄다는 점을 알 수 있습니다. 다만 현장 장비로 옮길 때는 5V 모듈, 3.3V GPIO, 레벨 시프터, 공통 접지 조건을 다시 따져야 합니다.
라즈베리파이는 리눅스 기반이라 센서 읽기 주기가 운영체제 스케줄링의 영향을 받을 수 있습니다. 반면 아두이노 계열 마이크로컨트롤러는 단순 루프에서 일정하게 센서를 읽기 쉽습니다. 그래서 빠른 반응이 필요한 안전 인터록은 마이크로컨트롤러에 맡기고, 라즈베리파이는 로그 저장과 네트워크 전송을 담당하게 나누는 설계가 안정적입니다.
- 아두이노: 단순 제어, 빠른 센서 읽기, 현장 테스트에 유리합니다.
- 라즈베리파이: 데이터 저장, 대시보드, MQTT 전송 같은 사물인터넷 기능에 유리합니다.
- 혼합 구성: 아두이노가 센서를 읽고 라즈베리파이가 상위 시스템과 통신하는 구조가 실무적입니다.
Q. 레벨 시프터는 꼭 넣어야 하나요?
5V 아두이노용 센서 모듈을 3.3V 라즈베리파이에 직접 연결하는 방식은 피하는 편이 좋습니다. 동작하는 것처럼 보여도 GPIO 허용 전압을 넘길 수 있고, 장기간 운용에서 고장 원인을 만들 수 있습니다. 양방향 레벨 시프터는 가격이 크지 않으므로 현장 장비라면 부품 하나를 아끼기보다 전압 경계를 명확히 하는 쪽이 낫습니다.
“프로토타입에서 ‘일단 된다’와 현장에서 ‘계속 된다’는 완전히 다른 기준입니다. I2C 센서 연결은 전압, 접지, 케이블을 도면에 남길 때부터 품질이 올라갑니다.”
노이즈가 많은 제어함에서는 소프트웨어 복구도 설계입니다
Q. 하드웨어를 고쳐도 가끔 실패하면 코드는 어떻게 짜야 하나요?
전문가는 하드웨어 안정화와 함께 임베디드 개발 코드의 복구 루틴을 반드시 넣으라고 말했습니다. I2C 읽기가 실패했을 때 프로그램이 그대로 멈추면 데이터 로거 전체가 죽은 것처럼 보입니다. 반대로 실패 횟수를 기록하고, 버스를 재초기화하고, 마지막 정상값과 오류 플래그를 함께 저장하면 현장 분석이 가능해집니다.
예를 들어 온도값이 갑자기 -127이나 0으로 들어왔을 때 바로 제어 명령에 반영하면 위험합니다. 센서값의 유효 범위를 정하고, 비정상 데이터는 폐기하거나 별도 상태 코드로 남겨야 합니다. 장치 드라이버와 개발환경의 관계를 더 넓게 이해하려면 디바이스 드라이버 통합개발환경의 개요 같은 기본 자료도 도움이 됩니다.
- 타임아웃 설정: 응답이 없을 때 무한 대기하지 않게 합니다.
- 재시도 횟수 제한: 같은 센서를 2~3회만 다시 읽고 다음 루프로 넘어갑니다.
- 버스 재초기화: 실패가 누적되면 I2C 장치를 닫고 다시 엽니다.
- 오류 로그 저장: 센서 주소, 시간, 실패 코드, 설비 상태를 함께 남깁니다.
Q. 데이터 보정은 어디까지 허용되나요?
평균값 필터나 이동중앙값 필터는 튀는 값을 줄이는 데 도움이 됩니다. 그러나 통신 실패를 필터로 숨기면 더 큰 문제가 됩니다. 필터는 정상 범위 안의 작은 흔들림을 줄이는 용도이고, 버스 오류나 비정상 응답은 별도 이벤트로 드러내야 합니다. 독자가 운영 중인 장비에서도 “값이 예뻐 보이는가”보다 “오류를 설명할 수 있는가”를 기준으로 코드를 점검해 보세요.
- 제어용 값과 기록용 원본 값을 분리합니다.
- 센서별 정상 범위를 코드 상수로 관리합니다.
- 통신 실패율이 일정 비율을 넘으면 알림을 발생시킵니다.
긴 배선이 필요하면 I2C를 고집하지 않는 선택도 있습니다
Q. 그래도 I2C 센서를 멀리 보내야 한다면 어떤 선택지가 있나요?
마지막 질문에서 전문가는 조금 다른 관점을 냈습니다. 모든 센서 연결을 I2C 통신으로 해결하려고 하면 설계가 오히려 복잡해질 수 있다는 것입니다. 센서가 제어함 문 가까이 있거나, 설비 곳곳에 흩어져 있거나, 케이블이 2m 이상 길어지는 조건이라면 I2C 버스를 억지로 늘리는 것보다 로컬 마이크로컨트롤러를 센서 근처에 두고 상위 통신을 RS-485, CAN, 이더넷, 무선 등으로 넘기는 구성이 더 튼튼할 수 있습니다.
물론 I2C 확장 칩, 버스 버퍼, 차동 I2C 솔루션도 있습니다. 하지만 부품을 추가할수록 디버깅 지점도 늘어납니다. 현장 유지보수 담당자가 오실로스코프 없이 멀티미터와 노트북만 들고 와도 문제를 찾을 수 있어야 한다면, 짧은 I2C 구간과 긴 산업용 통신 구간을 분리하는 방식이 운영 측면에서 더 친절합니다.
- 센서가 보드 근처: I2C를 그대로 쓰되 배선과 풀업을 관리합니다.
- 센서가 1~2m 이상 떨어짐: 버스 버퍼 또는 센서 근처 보조 MCU를 검토합니다.
- 노이즈가 강한 설비 주변: RS-485나 CAN처럼 장거리와 차동 신호에 강한 방식을 고려합니다.
- 데이터가 클라우드로 올라감: 라즈베리파이, MQTT, 로컬 캐시를 조합해 사물인터넷 구조로 나눕니다.
Q. 반대로 단순함 때문에 I2C를 유지해야 한다는 의견도 있나요?
있습니다. 모든 프로젝트가 산업용 표준 통신까지 필요로 하지는 않습니다. 짧은 거리의 실험 장치, 교육용 키트, 소형 데이터 로거라면 I2C는 여전히 빠르고 경제적인 선택입니다. 센서 모듈이 풍부하고 예제 코드도 많아 처음 전자회로와 센서 연결을 배우는 독자에게 진입 장벽이 낮습니다.
따라서 핵심은 “I2C가 약하다”가 아니라 “설치 환경에 맞게 범위를 정해야 한다”입니다. 책상 위 프로토타입이라면 단순한 I2C 버스가 생산성을 높이고, 배전반 내부의 장거리 배선이라면 다른 통신을 섞는 편이 낫습니다. 전문가의 마지막 말처럼, 좋은 설계는 특정 부품을 끝까지 밀어붙이는 것이 아니라 센서가 놓이는 장소와 유지보수자의 손을 함께 상상하는 데서 시작됩니다.
- 다음글I2C 센서 키트, 예산별로 오래 쓰는 구성법 26.09.25
등록된 댓글이 없습니다.