분석하기도 힘들고, 정말 난해했던 것이 바로 카메라의 전원을 켰을 때의 데이터 분석입니다. 데이터 양도 엄청나게 많고, 데이터 통신의 양상도 다른 때와 많이 다릅니다.
더구나, 다양한 조건에서 테스트 해 볼 수도 없어서, 데이터의 공통점/차이점을 이용해 분석할 수도 없습니다. 오로지 여러 렌즈를 끼우면서 분석해야 하는데, 제가 가진 NX 렌즈가 달랑 4개 밖에 없어서….
아래 캡쳐는 NX 바디와 렌즈간 전형적인 통신의 형태를 보여줍니다. 아주 착한 모습입니다. 1번 핀은 클록 주파수를 팅겨주고, 거기에 맞춰서 명령을 바디에서 보내면, 렌즈는 5번 핀을 통해 데이터 보낸다고 알리고, 바디에서 클록 주파수를 팅겨주면 거기에 맞춰서 데이터 전송하는….
그런데, 요게 전원을 켤 때, 렌즈와 바디간의 데이터를 보면 아주 못됐습니다.
아주 쉬지도 않고, 마구마구 데이터를 서로 주고 받습니다.
어쨌든 이런 한계점이 분명하기 때문에, 전원을 켰을 때의 데이터를 분석을 하지 못한 부분이 태반입니다.
그래도 대충 정리를 해본다면….
일단 전원을 켜면 워낙 데이터가 밀도있게 전송이 되기 때문에, 아마도 프로세서에서 안정성을 원했던지, 1번과 2번 단계에선 상대적으로 느린 250 KHz의 속도로 통신을 하고, 일단 폭풍전송이 끝나고 나면 원래의 전송 속도인 2MHz로 복귀합니다.
‘폭풍 전송’ 구간은 위의 2번 구간입니다. 이 부분을 좀 더 풀어보면…
대충 위와 같은 세부 블럭으로 구분할 수 있습니다.
렌즈의 촛점 거리 구간이라거나… 렌즈의 고유 특성 같은 것은 제 막눈으로는 찾아지질 안았습니다. 아마도, 바디 내에서 각 렌즈의 DB가 심어져 있지 않나 하는 추측이 듭니다. 그게 아니라면, 그냥 단순히 눈에 쉽게 띄지 않도록 잘 감춰서 통신을 할 수도 있을 것입니다.
위 다이어그램의 Block 3에서 정의 된 렌즈 세부 자료는 위에 위에 그림의 3번 단계에서 세부적으로 바디로 부터 렌즈로 요청이 되어져 올라갑니다. 이 부분도 거의 분석이 안되는 부분입니다.
예를 들자면…. 30팬의 블럭 3의 구조를 보면… 아래와 같습니다.
06 50 01 50 02 50 03 50 07 50 08 50 09 00 00 00
첫째 바이트는 이 블록 안에 6개의 정의가 있다고 합니다. 정의는 01, 02, 03, 05, 08, 09 가 있다고 하죠….
그리고 이 정의가 3번에서 다시 바디가 세부 데이터를 렌즈에 요청합니다.
CMD:05 10 06 50 01
DAT:0F 20 01 00 02 01 00 00 02 00 04 00 01 02 03
CMD:05 10 06 50 02
DAT:0D 20 01 00 02 01 01 01 02 00 02 00 01
CMD:05 10 06 50 03
DAT:0D 20 01 00 02 01 00 00 02 00 02 00 01
CMD:05 10 06 50 07
DAT:11 20 01 00 04 20 00 5C 00 5C 01 00 33 05 05 00 01 <– 렌즈 최원점 (00 33)과 최근점(05 05)의 포커싱 위치로 의심되는 값
CMD:05 10 06 50 08
DAT:0C 20 01 00 02 00 01 01 01 01 01 01
CMD:05 10 06 50 09
DAT:0C 20 01 00 02 20 01 01 01 01 1F 01
제 추측입니다만, 예전에도 설명을 드렸지만, 모든 패킷의 첫번째 바이트는 그 패킷의 크기입니다. 2번 단계의 ‘폭풍 전송’ 모드에서도 한번에 데이터를 전송할 수 있는 양이 1바이트로 표현할 수 있는 크기 즉… 255 바이트 입니다. 아마도 이런 식으로 주 정의 부분과 부 정의 부분을 결합하여 데이터 전송의 패킷 크기의 한계를 보완하려고 한 것으로 추측됩니다.
뭐… 대충 이상입니다. ^^
이제 부터는 데이터 분석은 실제 렌즈 어댑터의 SW/HW를 개발하면서 병행할 것입니다. 이 이상 데이터만 갖고 분석하는 것은 이제 한계에 다다른 것 같습니다.
어댑터를 직접 구현하면서 의심스런 부분에 값을 변경하면서 적용해보면, 좀더 이해에 도움이 될 것입니다…