저전력 성능은 곧 유지보수 비용과 직결됩니다. IoT 장치의 전류소모가 최소화되어 있지 않으면 배터리 교체/충전 주기가 짧아지고, 이로 인해 현장으로의 인력 투입 주기가 짧아지게 되며, 궁극적으로 IoT 망의 유지보수 비용이 증가하는 원인이 됩니다.

저희 Nol.A를 도입한 파트너사 중에는 종종 저희에게 저전력 디버깅을 요청합니다. 회로 상의 각 파트별 소모전류의 합보다 실제 전체 소모하는 전류가 클 경우, 원인은 대체로 소프트웨어의 오류이거나 회로의 설계 오류 중 하나가 됩니다. 요새는 칩 제조사에서 레퍼런스 회로를 워낙 잘 제공하고 있기 때문에 대다수의 경우 소프트웨어의 오류일 확률이 높죠. 저희는 고객들의 요청을 받고 소프트웨어 오류의 경우 수정을, 하드웨어 오류의 경우 역으로 설계 제안을 보내기도 합니다.

이번에 저희가 받은 요청은 MCU와 SX1276 LoRa transceiver의 조합으로 구성된 하드웨어에서 소모전류가 너무 크다는 내용이었습니다. 데이터시트상 해당 MCU는 sleep 상태에서 2.3 uA를, SX1276은 sleep 상태에서 0.2 uA를 통상 소모하기 때문에 2.5 uA 정도가 나와야 합니다. 그런데 실제로는 12 uA 정도가 소모되고 있다는 것이었습니다. 이럴 경우, 참 난감하지요. 전류가 흐르는 게 눈이 보이는 것도 아니고, 부품을 다 떼어내면서 추적하는 것도 힘든 일입니다.

사실 저희라고 해서 확실한 방법이 있거나 계측 솔루션 같은 것이 있는 것은 아닙니다. 그저 각 칩의 evaluation kit들로 동일한 회로를 구성하여 증상을 재현시키고, 그로부터 세는 전류와 그 원인을 찾아냅니다.

이번 작업의 MCU는 TI의 MSP430 계열입니다. TI는 모든 MSP430 MCU에 대해 각 패키지별 개발 보드를 제공하고 있습니다. 개발보드를 구매하면 아래와 같이 MCU를 직접 끼워넣을 수 있는 소켓을 갖춘 보드와 MCU 등이 포함되어 있죠.

SX1276을 디버깅하기 위한 개발보드로는 제조사인 Semtech에서 개발한 mbed shield SX1276MB1xAS 가 있습니다.

약간 무식하지만 아래와 같이 점퍼선으로 다 이어버립니다. 그리고 문제가 되는 타겟의 것과 가능하면 동일한 이미지를, 어렵다면 유사하게 재현한 이미지를 올립니다.

실험 결과, 문제의 12 uA도 아니고, 20 uA 정도가 나왔습니다. 이 글을 쓰고 있는 지금이야 당연한 결과로 보이지만, 그 때 당시에는 참 난감했습니다. 그래도 어쩔 수 없죠. 저 상황에서 MCU와 RF의 소모 전류를 각각 따로 측정합니다. 그 결과, MCU는 정상적으로 2.5 uA 정도가 나왔지만, RF가 18 uA 정도가 나옵니다.

원인은 바로 SX1276 shield의 RF front-end에 있는 2개의 PE4259 RF switch에 의한 것으로 보입니다. 아래와 같이 2개의 PE4259에 항상 전원이 공급되고 있습니다. (전체 회로도)

PE4259의 데이터시트를 보니 typical 9 uA를 소비한다고 하네요. 9uA라니… IoT 분야에서는 너무나 큰 전류 소모입니다.

다행히 PE4259에서는 single pin control 방식과 complementary pin control 방식을 모두 지원하고 있습니다. 여기서 single pin control 방식은 VDD (Pin 6)에 3V를 항상 공급하면서 CTRL 핀 (Pin 4)을 제어하는 방식을 말하고, complementary pin control 방식은 별도의 상시 공급전압 없이 VDD (Pin 6)와 CTRL 핀 (Pin 4)에 모두 3V CMOS logic 핀을 연결하여 사용하는 방식을 말합니다.

물론 위 Table 6에는 나오지 않았지만, Pin 4와 6 모두 Low 상태로 두면 별도로 전류를 소모하지 않을 것으로 예상됐습니다. 그리고 실제 실험 결과로도 확인을 했습니다.

사실 Semtech이 왜 이런 reference 회로를 제공했는지 아쉬울 따름입니다. 열심히 자료 조사를 하다 보니, SX1276의 후속작인 SX126x의 reference 회로에는 PE4259 complementary control 방식을 사용했네요. 그렇다면 Semtech도 이 문제를 인지하고 있었을 텐데, SX1276 reference 회로도 업데이트를 해줬으면, 그게 어렵다면 관련 문서에 코멘트라도 달아줬으면 어땠을까 하는 생각이 드네요.

아쉽긴 해도, 이제라도 원인을 찾아냈으니 다행이긴 합니다. 고객님께 씁쓸하게 결과를 송부하고 이렇게 글을 올려봅니다. 이렇게 또 한 건 해결 아닌 해결을 했네요. 관련 예제는 여기에서 찾아볼 수 있습니다.