- 세상의 모든 계산기 자유(질문) 게시판 리뷰 ()
모니터 수리기 (CCFL을 LED로 개조 DIY)
-
- 2020.02.25 - 00:01 2017.01.11 - 02:18 5325 6
1. 대상
10년된 모니터가 한대 있습니다. 삼성 LTM210M2-L02 액정 패널을 사용한 XP210WL 이라는 모델명의 제품입니다.(회사는 망) 예전에 제가 쓰다가 본가에 놓고 왔고, 아버지께서 간혹 사용하셨던 제품입니다.
오랫만에 가져와서 보니
- 어댑터는 (한번 교체했던 것인데도...) standby 모드에서 약간의 고주파음이 들리고
- power on 이후 노이즈가 약간 보이고, 시간이 지나면 눈에 띄는 노이즈는 없어지지만, 화면이 지저분하다는 느낌이 들었습니다.
일단 오래 써서 내부 부품 일부의 수명이 다한 것 같다는 느낌이 들었습니다. 그리고 지금껏 사용해 본 경험상 어댑터(12V 5A)도 약간 빠듯하다는 느낌도 들었습니다.
그래서 겸사겸사 CCFL Backlight 를 전력소모가 적다는 LED로 개조하는 작업을 해 보았습니다.
2. 작업 사진
모니터를 뜯어보니 인버터 콘덴서가 부풀어 있는 것이 눈에 띄었습니다. AD보드는 외견상 멀쩡해 보였습니다(그러나 실제로는 문제가 있어 나중에 콘덴서 교체를 하였습니다)
패널을 완전 분해해야 하는데... (중간 과정은 복잡한데 다 생략)
패널의 위/아래에 장착되어 있는 CCFL 램프(아래 사진)를 제거하고,
구입한 LED 램프(아래사진)로 교체하여주면 됩니다.
교체한 LED 바는 사이즈가 딱 맞지 않아서 고정되지 않기 때문에, 고정을 위해서 3M 열전도 테잎이 있으면 최상이고, 없으면 그냥 접착력 좋은 양면 테잎이라도 있어야 하는데... 현재는 둘 다 없는 관계로 문구용 테잎으로 대충 바르고, 글루건으로 양 끝단만 살짝 고정시켜 주었습니다.
3. 결과
CCFL도 딱히 문제가 있어서 갈았던 건 아니었기 때문에, 확 좋아진 느낌은 받지 못했습니다. 그보다도 문제는 노이즈였는데, LED 개조 후에도 노이즈 개선이 되지 않았습니다.
결국 AD 보드의 콘덴서(캐패시터) 중에서 큰 것을(470㎌ 25V, 16V ->470㎌ 25V*2개) 교체하고 나서야, 노이즈가 많이 없어졌고, 깔끔한 화면을 볼 수 있었습니다.
어댑터 문제도 아니었고, 인버터 문제도 아니었고 AD보드가 주범이었던 모양입니다. (물론 복합적 결과로 나타났을 가능성도 있습니다.)
4. 평가
- 패널 분해는 꽤 까다롭다. - 액정/필름 손상 위험 있음. 먼지 유입 가능성 매우 높음.
- CCFL to LED 교체 자체는 간단하다. - 부품값(LED+드라이버) 1만 4천원 ~ 1만 9천원 (인터넷 가격 기준)
- 백라이트 문제가 확실하지 않은 이상 교체는 신중히 결정할 것. (요즘 중소기업 20인치급 FHD IPS/VA 모니터가 10만원 내외인데, 굳이 위험을 감수하고, 부품비 들여가면서까지 꼭! 고쳐야 할 이유가 있는지 생각해 볼 것)
-
25
댓글6
-
세상의모든계산기
2년 정도 사용하였는데, 그동안 큰 문제는 없었습니다.
다만, 상단 LED 바 쪽(상단 2~3cm)에 빛이 뭉쳐보이는 현상이 있습니다.
정면에서는 괜찮은데, 상/하단 (30도 이상) 에서 보면 눈에 확 띄눈군요.또, 정전기에 조금 민감한데, LED 문제는 아니라고 생각되고, AD보드쪽 부품에 문제가 있지않나생각하고 있습니다.
(저번에 콘덴서 교체할 때 얍실하게 생긴 일부는 용량이 맞지 않아서 교체하지 못했습니다)* 그 사이 모니터 신품 가격은 더 내려갔네요. ㅎㅎ
세상의모든계산기 님의 최근 댓글
예시11) 선형 연립방정식에서 답이 false 로 나올 때 https://allcalc.org/55823 2025 10.22 approx(참 해) 값이 이상하게 튀는 것 같아서 AI를 이용해 (python 으로) 구해보았습니다. * python 의 유효자릿수가 nspire 의 유효자릿수(14자리~15자리)보다 더 길기 때문에 시도하였습니다. ** 원래는 wolfram alpha 로 구해보려고 했는데, 울프람에서는 수식 길이가 너무 길다고 거부하는 바람에 포기하였습니다. 그 결과, AI approx(참 해) 값은 정상 범주에 포함되었고, 이는 solve()로 구한 대부분의 결과값과 유사하였습니다. 그럼 nspire 의 approx(참 해)는 왜 튀었나? 참 해에 더하기,빼기,곱하기,나누기 가 너무 많이 포함되어 있다보니, 모두 계산하고 나면 오차가 누적&증폭되어 버리는 것 같습니다. 그래서 오히려 solve의 numeric 한 접근보다도 더 큰 오차가 발생한 듯 하고, 그래서 적절한 해의 x 구간을 벗어나버린 듯 합니다. 그것이 처음의 solve 에서 false 를 이끌어낸 주 원인이 아니었을까요? (추정) 2025 10.21 그래프로 확인 그래프 함수로 지정하고, 매우 좁은 구간으로 그래프를 확대해 보면 불연속적인 그래프 모습이 확인됩니다. 이것은 한계 digits(15자리) 이상을 처리하지 못하기 때문일 것이구요. 다만 특이한 점은, 그래프상으로 교점에 해당하는 구간이 73.049507058477≤x≤73.049507058484 사이로 나오는데 -> 이 구간은 'solve에서 여러 방법으로 직접 구해진 해들'은 포함되는 구간입니다. -> 하지만, '참값인 해를 계산기로 구한 appprox 값 x=73.049507058547'은 포함되지 않는 구간입니다. 2025 10.21 tns 파일 첨부 sol_num_vs_exact.tns 2025 10.21 검증하면 1번 식을 x에 대해 정리하고, → 그 x 값을 2번 식에 대입해 넣으면 → 그 결과로 x는 사라지고 y에 대한 식이 되니, y에 대해 정리하면 참값 y를 얻음. 얻은 y의 참값을 처음 x에 대해 정리한 1번식에 대입하면 참 값 x를 얻음. 구해진 참값의 근사값을 구하면 x=73.049507058547 and y=23.747548955927 참 값을 approx() 로 변환한 근사값은 원래 방정식 모두를 만족할 수 없지만, linsolve() 로 찾은 근사값과, AI로 참 값을 근사변환한 값은 원래 방정식 모두를 만족할 수 있습니다. 2025 10.21