사용할 노트북을 대고 자를 위치를 표시한다.
위치대로 자른다.
반대편도 마찬가지로 자르고 모서리 부분을 견고하게 하기 위해서 테이프로 마감 처리한다.
잘 잘라졌는지 올려 본다.
뭔가 좌우가 맞질 않으면 주춧돌 용도의 무언가를 언져서 테이프로 붙여 버린다.
이젠 자우가 잘 맞는다. 잘 된다.
2012년 6월 28일 목요일
2012년 6월 26일 화요일
2012년 6월 25일 월요일
heatpipe 구매 가능한 미국 사이트
4개의 10W LED를 식히려고 4개의 알루미늄 히트 싱크와 두개의 0.38W 팬을 사용하다가 그 많은 열을 다 방출할 수 없다는 것을 발견하고 heatpipe라는 물건과 구멍이 송송 뚤린 aluminum perforated sheet라는 것을 수배해 보았다.
heatpipe는
http://www.newark.com/jsp/search/browse.jsp?N=422+2203+200539&Ntk=gensearch&Ntt=heat+pipes&Ntx=mode+matchallpartial
에서 Aluminum Perforated Sheet는
http://www.mcmaster.com/#standard-perforated-sheets/=i4fy3d
에서 찾았다.
직경 5mm에 길이 100m이 정도의 heatpipe와 두께가 1mm가 안되는 구멍이 0.1875"인 perforated sheet를 사용하면 최적의 열전도율을 보일 것이다.
하지만, 하지 말란다. 의욕 상실이다.
heatpipe는
http://www.newark.com/jsp/search/browse.jsp?N=422+2203+200539&Ntk=gensearch&Ntt=heat+pipes&Ntx=mode+matchallpartial
에서 Aluminum Perforated Sheet는
http://www.mcmaster.com/#standard-perforated-sheets/=i4fy3d
에서 찾았다.
직경 5mm에 길이 100m이 정도의 heatpipe와 두께가 1mm가 안되는 구멍이 0.1875"인 perforated sheet를 사용하면 최적의 열전도율을 보일 것이다.
하지만, 하지 말란다. 의욕 상실이다.
황당한 AMD의 fglrx-driver
debian 패키지 관리자로 확인도 없이 dist-upgrade를 진행하다가 벌써 두 번째 LCD를 갈아야 했다. 한번은 써비스 기간중이라 공짜로 한번은 ebay를 통해서 $15달러를 들여서 그래서 아예 open source debian 드라이버를 쓰기로 작정했다. 하지만 Kicad가 굉장히 느려진다는 문제점이 있다. 하지만 fglrx-driver처럼 갑자기 사라져서 GUI로 부팅이 안되고 root로 터미날 로그인을 하였다가 logout시 lcd가 날라가는 경우는 없을 것이다.
오프라인 지도 생성기인 Mobile Atlas Creator의 Sqlite Library문제
리눅스에서 Mobile Atlas Creator로 오프라인 맵을 생성하려고 format을 설정한 후 생성을 시작하면
데
다음과 같은 에러 메시지를 내보낸다.
"Unable to find SQLite Libraries"
이 문제는 SQLite 방식의 맵을 생성하는데 필요한 적절한 SQLite 라이브러리가 없다고 하는 것 같다.
출처 : http://www.mychinamoto.com/forums/showthread.php?2149-Offline-maps-on-Android-in-China/page4
다음의 http://files.zentus.com/sqlitejdbc/sqlitejdbc-v056.jar 을 다운로드하고
Mobile_Atlas_Creator.jar가 위치한 /usr/share/Mobile Atlas Creator 밑에 복사한다.
그리고 sqlitejdbc의 버전을 인지 하기 위해서 심볼릭 링크를 다음과 같이 만든다.
/usr/share/Mobile Atlas Creator# ln -s sqlitejdbc-v056.jar sqliejdbc.jar
그럼 맵 생성이 이루어 질 것이다.
근데 아쉽게도 그 많은 지도 소스가 많이 사라졌다.
아마도 맵 제공자와 프로그램 개발자 사이에 안좋은 일들이 있었나 보다.
출처 : http://sourceforge.net/apps/phpbb/mobac/viewtopic.php?f=1&t=1&start=0
MJEG 대 H.264
[출처] http://ipvm.com/report/mjpeg_vs_h264
MJPEG 대 H.264
by John Honovich, IPVM posted on Apr 18, 2009 About John Contact John
Share on linkedin Share on twitter Share on facebook Share on email
최근에 IQinVision은 MJPEG의 장점을 옹호하는 글을 내놓았다.
[2010년 12월에 올라온 내용: 우리는 MJPEG과 H.264를 비교하기 위한 광범위한 테스트를 실시하였다. 우리의 MJPEG 대 H.264 테스트 결과를 읽어 보시라.]
나는 기술적으로 정확하고 잘쓰여진 읽을 가치가 있는 기사를 찾는 도중에 응용분야의 성향과 경제성은 MJPEG은 거의 항상 기피되어지도록 만든다. H.264는 지금 바로 뜨꺼운 존재이기 때문에 이러한 현상이 일반적인 요구사항으로 여겨지도록 만든다. 그러나 이 논의는 이러한 논재를 다루는 경제적이고 기능적인 동작들은 조사하는데 도움을 줄 수 있다.
Jason의 주된 주장은 다음과 같다:
1. 움직이는 카메라나 높은 변화를 갖는 영상에서는 MPEG4와 H.264는 MJPEG에 비해 상대적으로 아주 적은 대역폭 이득을 제공한다.
2. 적절한 네트워크 구성은 최악의 시나리오에서의 요인 구성을 요구한다. 그레서 여러분들은 MJPEG, MPEG4, 그리고 H.264를 사용할 지의 여부에 따라서 그에 들어 맞는 대역폭 총량에 부합하도록 할 필요가 있을 것이다.
3. MJPEG은 프레임간의 압축을 수행을 하지 않기 때문에 더 높은 품질을 제공한다.
4. MJPEG과 달리 MPEG-4를 갖는 밴더들은 표준에서 빚겨나 있어서 잠재적인 통합비용이 증가한다.
나의 그에 상응하는 입장은 다음과 같다:
1. 대부분의 사용자들에게 일반적으로 카메라는 낮거나 일반적인 움직임을 갖기 때문에 MPEG-4나 H.264이 중요한 이득으로 해석될 수 있다. 세상의 대부분의 카메라는 고정되어 있다. 대부분의 카메라는 움직임이 거의 없거나 아예 없는 낮 시간의 상당한 기간을 갖는다. PTZs(카메라를 움직이는 규약)에 대해서 조차 PTZs는 자주 집을 감시하는 위치에 놓이거나 5-10초 마다 반복되는 작업이 되풀이 된다.
2. 많은 아마도 대부분의 기관은 최악의 경우에 대한 대역폭 예산을 책정하지 않는다. 때때로, 기관들은 추가적인 용량에 대한 비용을 지불하길 원하지 않는다. 그러나 때때로 이미 존재하는 인프라를 재사용하고자 하는 재약때문에 그렇지 않을 수도 있다. 다시 말하자면, 기관들은 일반적으로 즉각적인 비용 감축을 위해서 자주일어나지 않는 화소변화에 대한 대비는 무시한다. 아마도 이것은 객관적으로 잘못되었다 하지만 이것이 일반적이다.
2a. Jason은 저장 공간에 대한 논의는 하지 않았다. 그러나 저장공간은 MJPEG으로 부터 멀어지게 만드는 가장 큰 경재성 요소이다. 나는 나의 1TB 하드 드라이브를 갖는 DVR/NVR이 단지 13일치만 기록하는 아무 많은 경우를 목격하였다. 왜 그럴까? 나는 최근에 우리가 MJPEG을 이용한 수 매가픽셀을 카메라를 장착하였던 것을 까맣게 잊고 있었던 것이다. 우리는 MJPEG에서 MPEG4로 의 전환만으로 1Mb/s의 절감을 할 수 있다고 말한다. 2개월 이상 동안 한 카메라에 대한 저장공간은 650 GBs이다. 이것은 아마도 각각의 MJPEG 카메라를 위해 사용되는 저장공간을 추가하는데 $300에서 $600 달러의 비용이 들것으로 추정된다.
3. 품질의 차이는 대부분의 구매자들이 허용할 정도로 충분히 근접해 있다. 특히나 비용 절감에 대해서.
4. 표준에서 벗어나는 현상에 대한 사항은 일반적으로 한번만 발생하는 비용 혹은 문제이다. 더 큰 규모의 설계에서 이것은 주로 문제가 된다.
종합적으로 네트워크와 저장공간 비용을 줄이는 경제성은 구매 결정을 유도하는 일반적으로 매우 중요한 예산과 운용 요소이다. megapixel 카메라의 제조업체가 H.264의 지원을 소개하기 위한 시작으로 IQinVison이 해놓은 것을 보는 것은 아주 흥미로울 것이다.
MJPEG 대 H.264
by John Honovich, IPVM posted on Apr 18, 2009 About John Contact John
Share on linkedin Share on twitter Share on facebook Share on email
최근에 IQinVision은 MJPEG의 장점을 옹호하는 글을 내놓았다.
[2010년 12월에 올라온 내용: 우리는 MJPEG과 H.264를 비교하기 위한 광범위한 테스트를 실시하였다. 우리의 MJPEG 대 H.264 테스트 결과를 읽어 보시라.]
나는 기술적으로 정확하고 잘쓰여진 읽을 가치가 있는 기사를 찾는 도중에 응용분야의 성향과 경제성은 MJPEG은 거의 항상 기피되어지도록 만든다. H.264는 지금 바로 뜨꺼운 존재이기 때문에 이러한 현상이 일반적인 요구사항으로 여겨지도록 만든다. 그러나 이 논의는 이러한 논재를 다루는 경제적이고 기능적인 동작들은 조사하는데 도움을 줄 수 있다.
Jason의 주된 주장은 다음과 같다:
1. 움직이는 카메라나 높은 변화를 갖는 영상에서는 MPEG4와 H.264는 MJPEG에 비해 상대적으로 아주 적은 대역폭 이득을 제공한다.
2. 적절한 네트워크 구성은 최악의 시나리오에서의 요인 구성을 요구한다. 그레서 여러분들은 MJPEG, MPEG4, 그리고 H.264를 사용할 지의 여부에 따라서 그에 들어 맞는 대역폭 총량에 부합하도록 할 필요가 있을 것이다.
3. MJPEG은 프레임간의 압축을 수행을 하지 않기 때문에 더 높은 품질을 제공한다.
4. MJPEG과 달리 MPEG-4를 갖는 밴더들은 표준에서 빚겨나 있어서 잠재적인 통합비용이 증가한다.
나의 그에 상응하는 입장은 다음과 같다:
1. 대부분의 사용자들에게 일반적으로 카메라는 낮거나 일반적인 움직임을 갖기 때문에 MPEG-4나 H.264이 중요한 이득으로 해석될 수 있다. 세상의 대부분의 카메라는 고정되어 있다. 대부분의 카메라는 움직임이 거의 없거나 아예 없는 낮 시간의 상당한 기간을 갖는다. PTZs(카메라를 움직이는 규약)에 대해서 조차 PTZs는 자주 집을 감시하는 위치에 놓이거나 5-10초 마다 반복되는 작업이 되풀이 된다.
2. 많은 아마도 대부분의 기관은 최악의 경우에 대한 대역폭 예산을 책정하지 않는다. 때때로, 기관들은 추가적인 용량에 대한 비용을 지불하길 원하지 않는다. 그러나 때때로 이미 존재하는 인프라를 재사용하고자 하는 재약때문에 그렇지 않을 수도 있다. 다시 말하자면, 기관들은 일반적으로 즉각적인 비용 감축을 위해서 자주일어나지 않는 화소변화에 대한 대비는 무시한다. 아마도 이것은 객관적으로 잘못되었다 하지만 이것이 일반적이다.
2a. Jason은 저장 공간에 대한 논의는 하지 않았다. 그러나 저장공간은 MJPEG으로 부터 멀어지게 만드는 가장 큰 경재성 요소이다. 나는 나의 1TB 하드 드라이브를 갖는 DVR/NVR이 단지 13일치만 기록하는 아무 많은 경우를 목격하였다. 왜 그럴까? 나는 최근에 우리가 MJPEG을 이용한 수 매가픽셀을 카메라를 장착하였던 것을 까맣게 잊고 있었던 것이다. 우리는 MJPEG에서 MPEG4로 의 전환만으로 1Mb/s의 절감을 할 수 있다고 말한다. 2개월 이상 동안 한 카메라에 대한 저장공간은 650 GBs이다. 이것은 아마도 각각의 MJPEG 카메라를 위해 사용되는 저장공간을 추가하는데 $300에서 $600 달러의 비용이 들것으로 추정된다.
3. 품질의 차이는 대부분의 구매자들이 허용할 정도로 충분히 근접해 있다. 특히나 비용 절감에 대해서.
4. 표준에서 벗어나는 현상에 대한 사항은 일반적으로 한번만 발생하는 비용 혹은 문제이다. 더 큰 규모의 설계에서 이것은 주로 문제가 된다.
종합적으로 네트워크와 저장공간 비용을 줄이는 경제성은 구매 결정을 유도하는 일반적으로 매우 중요한 예산과 운용 요소이다. megapixel 카메라의 제조업체가 H.264의 지원을 소개하기 위한 시작으로 IQinVison이 해놓은 것을 보는 것은 아주 흥미로울 것이다.
피드 구독하기:
글 (Atom)