so cooooooooooool

Little endian format의 데이터 처리

2010-11-09T22:45:00.001-08:00

tinyos-1.x 버전에서는 Listen 이나 기타 시리얼 프로그램을 통해 패킷을 확인하고 분석하는데 요 녀석이 리틀엔디안 포맷이라 실제 데이터를 읽을 때는 바이트 단위로 앞뒤를 뒤집어서(?) 확인해야 한다.
12bit 이상의 AD를 사용하는 센서나 기타 하드웨어들은 2바이트 혹은 그 이상의 값을 뿌려준다. T1과 T2 버전은 방식이 달라 매번 헷갈린다.(참고로 T1은 리틀엔디안, T2는 빅엔디안)
간단하게 산술식을 통해 값을 변환한다든지 할 때 디버깅하기에는 안성맞춤인데, 어쩌다가 한번씩 만들려면 생각이 안 나서 기록을 해야겠다.
T1의 경우 예를 들어 packet의 10번째와 11번째의 값이 내가 원하는 값이라고 했을 때, packet[11] + packet[10] 이 되어야 하므로,
uint16_t value = ((0xFF00 & packet[11]) << 8) + (0x00FF & packet[10]);
요로케 처리하면 해당 값이 처리 된다.
T2에서는 uint16t value = packet[10] + packet[11]; 하시면 되겠다.
이제 value를 가지고 원하는대로 지지고 볶아서 요리하면 끝.

Active Message ID Allocation in TinyOS 2.1

2010-11-03T01:31:00.001-07:00

The reserved pool is in the range 0-127 (0x00-0x7F). The AM IDs in this range are used by protocols distributed with TinyOS.

Here is a list of allocations for TinyOS 2.1:

* 0x70 - 0x7F are reserved for collection protocols maintained by
  the Network Protocol Working Group.

  0x70 - CTP routing beacon and LEEP (''tos/lib/net/ctp'', TEP 119, 123, and 124)
  0x71 - CTP data packets (''tos/lib/net/ctp'', TEP 119, 123)
  0x72 - CTP debug messages (''tos/lib/net/ctp'')
  0x73 - MultiHopLQI routing beacon (''tos/lib/net/lqi'')
  0x74 - MultiHopLQI data packets (''tos/lib/net/lqi'')
  0x75 - MultiHopLQI debug messages (''tos/lib/net/lqi'')

* 0x60 - 0x6F are reserved for dissemination protocols maintained by
  the Network Protocol Working Group.

  0x60 - Drip (''tos/lib/net/drip'', TEP 118)
  0x61 - DIP (''tos/lib/net/dip'', TEP 118)

* 0x50 - 0x5F are reserved for Deluge (''tos/lib/net/Deluge'')
  maintained by the Network Protocol Working Group.

  0x50 - AM_DELUGEADVMSG (advertisements)
  0x51 - AM_DELUGEREQMSG (requests)
  0x52 - AM_DELUGEDATAMSG (data)
  0x53 - DELUGE_AM_FLASH_VOL_MANAGER (flash volume manager)
  0x54 - DELUGE_AM_DELUGE_MANAGER (deluge manger)

* 0x3F - TinyOS NALP code (TEP 125) reserved by the Core Working
  Group.

비트 연산자를 사용하는이유(비트 연산을 하는 이유)

2010-09-20T11:40:00.000-07:00

오늘 지인에게 비트 연산자를 사용하는 이유(비트 연산을 하는 이유)가 무엇이냐는 질문을 받았다.
비트 연산을 하는 가장 큰 이유는 연산속도다. bit는 최소정보단위로 다른 추상화된 정보들과 다르게 즉시 해석되어 전달되므로 연산 속도가 매우 빠르다는 장점이 있다.
다음으로 제어에 뛰어난 성능을 발휘한다. 레지스터의 직접 접근을 통해 bit 레벨 조작이 가능하다.
또한, 비트연산을 응용하면 복잡한 로직도 비교적 짧은 코드로 만들 수 있으며, 메모리의 최적화가 가능하다. 하지만 내공이 필요하다.

이제 비트연산자는 고급 언어의 등장과 컴퓨팅 파워의 향상으로 하위레벨의 펌웨어등에서나 찾아볼 수 있는 귀한 녀석이 되었다.

기술사에 도전하다.

2010-09-13T21:16:00.001-07:00

항간에 “실력도 없고 경력도 없고 아는 건 쥐뿔도 없으면서 무슨 기술사” 라고 하지만 해 보고 이야기 하자. 아직 나는 시작도 겪어보지도 않았잖아.

그런 유쾌하지 않은 말들로 날 시험하지 마. 나에겐 한 번쯤 도전해 볼 만한 가치가 충분하니까…

더 큰 포부와 비전을 위해 화이팅!! (더도 말고 덜도 말고 항상 오늘만 같아라.)

What?, So What?, Now What?

2010-09-12T22:41:00.001-07:00

생각의 프레임워크…

어떤 생각에 있어 그 틀을 잡기 위한 세 가지 질문에 대한 것으로 사고하는 능력을 업그레이드 할 수 있는 도구이다.

What?

관찰의 단계. 접한 새로운 정보를 받아들이는 단계로 그 대상을 파악하는 것으로 볼 수 있다.

So What?

받아들인 정보를 반영하는 단계. 그 정보가 나에게 어떤 영향을 주는지, 나와 무슨 상관이 있는지 생각해 볼 수 있다. 만약 아무 상관이 없다면 다음 단계로 진행할 필요가 없다.

Now What?

적용의 단계. 이제 내가 무엇을 해야 하는지를 생각해 본다. 구체적으로 어떻게 적용할 것인지, 어떻게 해결할 것인지를 생각해 볼 수 있다.

- futureshaper.tistory.com -

moodle LMS(Learning Management System)

2010-09-07T01:25:00.001-07:00

moodle은 온라인 학습관리시스템으로 오픈소스로 제공된다.

reference site : http://www.moodle.org/

* vsftpd 설치

$> apt-get install vsftpd
$> vim /etc/vsftdp.conf
------------------------------
…
anonymous_enable=NO
local_enable=YES
write_enable=YES
…
------------------------------
$> /etc/init.d/vsftpd restart
* LAPM 설치
게시물 참조.
* gd library 설치
$> apt-get install php5-gd
$> /etc/init.d/apache2 restart
* LAPM 설정
$> vim /etc/apache2/mods-available/php5.conf
------------------------------------------------------------------------
…
AddType application/x-httpd-php .php .phtml .php3 html
…
-------------------------------------------------------------------------
$> vim /etc/php5/apache2/php.ini
---------------------------------------
…
memory_limit=40M
session.bug_compat_warn=0
post_max_size=16M
upload_max_filesize=16M
…
---------------------------------------
$> /etc/init.d/apache2 restart
* phpMyAdmin 설치
$> cd /var/www
$> wget http://ftp.superuser.co.kr/pub/phpmyadmin/phpMyAdmin-2.5.4-php.tar.bz2
$> tar xvfz phpMyAdmin-2.5.4-php.tar.bz2
$> mv phpMyAdmin-2.5.4 phpMyAdmin
$> cd /phpMyAdmin
$> vim config.inc.php
--------------------------------------------------------------------------
…
$cfg[‘Servers’][$i][‘auth_type’]=’http’;
$cfg[‘Servers’]['$i'][‘password’]=’mysql root password 입력’;
--------------------------------------------------------------------------
* phpMyAdmin 설정
1. http://server/ ip address/phpMyAdmin 접속

2. 새 데이터베이스 만들기

‘moodle’ 로 DB 생성.

정상적으로 DB가 생성되면 시작페이지로 이동.
3. 사용권한 설정

페이지의 사용권한 탭 클릭.

새로운 사용자 추가를 위해 클릭.

위와 같이 로그인 정보를 입력 후 실행 버튼 클릭.

DB 권한 수정을 위해 ‘moodle’을 선택.

위와 같이 DB에 관련된 모든 권한에 체크.
* moodle 설치
http://download.moodle.org/ 에서 최신 릴리즈 버전을 다운로드 후 해당 파일을 /var/www 폴더로 이동
$> tar xvfz moodle-1.9.9.tgz
$> chmod –R 777 moodle
/var 폴더내에 moodledata 폴더 생성
$> mkdir moodledata
$> chmod 777 moodledata
$> chown –R nobody.nogroup moodledata
설치를 위해 웹브라우저를 이용한다.
http://192.168.1.31/moodle

Next 를 선택하고 설치 중간에 필요한 정보를 입력하고 계속 설치.
설치가 완료된 후 페이지 뷰를 위해 설정에 필요한 내용을 추가로 입력.

리눅스에서 특정 문자 및 문자열 찾기

2010-09-05T18:32:00.001-07:00

리눅스에서 찾고자하는 문자를 포함하거나, 특정 문자열을 찾을 때 다음과 같은 방법을 이용하면 된다.

ex) opt/tinyos-1.x/tos/lib 폴더에서 MHOP_QUEUE_SIZE 를 찾고자 할 경우

$>find /opt/tinyos-2.x/tos/lib –type f –exec grep ‘MHOP_QUEUE_SIZE’ {} /dev/null \;

또 다른 방법으로는 해당 폴더의 위치로 이동하여

$>grep –rn MHOP_QUEUE_SIZE *

위와 같은 방법을 통해 어느 위치에 해당 내용이 있는지 쉽게 확인할 수 있다.

10대 유망 기술

2010-08-30T01:41:00.001-07:00

전자부품연구원(KETI)에서 올 초 10대 유망 기술 분야를 발표했다. 2010년 이후 미래 산업을 전망한 유망 기술들로 8월 현재 진행되고 있는 사항들을 뉴스 등의 매스컴을 통해 쉽게 접할 수 있는 내용들이 다수 있다.

1. 스마트그리드
2. 3D TV
3. LED/OLED 조명
4. Interactive UI
5. Beyond 4G
6. 악성코드 분석 및 대응기술
7. 저전력 SoC
8. 차세대 음장기술
9. 고효율/고속충정 에너지 저장기술
10. 무선에너지 전송/충전

File Transfer (peer to peer)

2010-08-29T20:11:00.001-07:00

: using two motes.

After receiving requests from so many people, I thought of writing this simple application which can transfer file between two computers
Assumptions:

Environment used is: TinyOS 2.1.0 with Ubuntu
Knowledge to compile "BaseStation" application (coming with TinyOS) with a modification in Makefile : CFLAGS += - TOSH_DATA_LENGTH
Basic understanding of file operations in Java
No other nodes are in the vicinity which are transmitting data at that time
Run SerialForwarder with Java applications in TinyOS
Transfer is only for "text files"

If not, please refer my previous posts on these topics or read from tinyos wiki/documentation
Steps:
General

Download the code from here
Install BaseStation in two motes
Put one mote in computer 1 and other in computer 2.
Run the SerialForwarder

Sender /Receiver

ECopy the FileSender folder
Open a shell, navigate to this above folder
Type in CLASSPATH=/opt/tinyos-2.1.0/support/sdk/java/tinyos.jar:.
Type in make
Type in java FileSender
Repeat the same with Receiver
Enter the file name with absolute path and extension at sender side
Wait for the message "File ended"

That is all folks :-)
PS:

Please come up with a reliable file transfer (like ftp)
Please fix this code for any (byte) file instead of text files
If you do any/both, please upload and post the link here

- by Gireesh -

Z-Monitor

2010-08-12T21:56:00.001-07:00

: A Monitoring Tool for IEEE 802.15.4 Wireless Personal Area Networks

http://www.z-monitor.org

Google Analytics

2010-07-29T23:21:00.000-07:00

엔터프라이즈급 무료 웹 분석 도구인 Google Analytics를 적용했다.
http://www.google.com/intl/ko_ALL/analytics/

로그 및 트래픽 분석, 최적화가 가능한 툴에 엑세스 하여 사이트 전략 및 마케팅, 운영등의 정책을 수립하고 강화하는데 도움이 되지 않을까?

Installation of Network Simulator NS2

2010-07-28T02:15:00.001-07:00

OS : xubuntu 9.04
NS2 Ver. : ns-allinone-2.34

xubuntu에 ns2 설치 전 꼭 필요한 필수 패키지들이 있다.
다음과 같이 설치한다.

$ apt-get install gcc, g++, libc6-dev, tcl8.5, tk8.5, tcl8.5-dev, tk8.5-dev, libxmu-dev

이미 xubuntu 배포판 설치 시 설치되어 있는 경우도 있으므로 패스~
패키지 설치가 끝나면 ns2 설치를 위해 다음 링크에서 2.34 버전을 다운로드 받는다.

http://sourceforge.net/projects/nsnam/files/allinone/ns-allinone-2.34/

다운로드 받은 ns-allinone-2.34를 /opt 에 위치시키고 압축해제 한 후 해당 폴더에서 ./install 명령을 통해 설치를 한다.

$ tar –xvf ns-allinone-2.34.tar.gz
$ ./install

설치가 정상적으로 완료되면 다음과 같은 내용을 볼 수 있다.
------------------------------------------------------------------------------
Please put /opt/ns-allinone-2.34/bin:/opt/ns-allinone-2.34/tcl8.4.18/unix:/opt/ns-allinone-2.34/tk8.4.18/unix
into your PATH environment; so that you'll be able to run itm/tclsh/wish/xgraph.

IMPORTANT NOTICES:
(1) You MUST put /opt/ns-allinone-2.34/otcl-1.13, /opt/ns-allinone-2.34/lib,
    into your LD_LIBRARY_PATH environment variable.
    If it complains about X libraries, add path to your X libraries
    into LD_LIBRARY_PATH.
    If you are using csh, you can set it like:
        setenv LD_LIBRARY_PATH <paths>
    If you are using sh, you can set it like:
        export LD_LIBRARY_PATH=<paths>

(2) You MUST put /opt/ns-allinone-2.34/tcl8.4.18/library into your TCL_LIBRARY environmental
    variable. Otherwise ns/nam will complain during startup.

After these steps, you can now run the ns validation suite with
cd ns-2.34; ./validate

For trouble shooting, please first read ns problems page
http://www.isi.edu/nsnam/ns/ns-problems.html . Also search the ns mailing list archive
for related posts.
-------------------------------------------------------------------------------

설치가 완료되면 path를 설정한다. ~/.bashrc 파일을 열고 다음의 내용을 추가한다.

# LD_LIBRARY_PATH
OTCL_LIB=/opt/ns-allinone-2.34/otcl-1.13
NS2_LIB=/opt/ns-allinone-2.34/lib
X11_LIB=/usr/X11R6/
USR_LOCAL_LIB=/usr/local/lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$OTCL_LIB:$NS2_LIB:$X11_LIB:$USR_LOCAL_LIB

# TCL_LIBRARY
TCL_LIB=/opt/ns-allinone-2.34/tcl8.4.18/library
USR_LIB=/usr/lib
export TCL_LIBRARY=$TCL_LIB:$USR_LIB

# PATH
XGRAPH=/opt/ns-allinone-2.34/bin:/opt/ns-allinone-2.34/tcl8.4.18/unix:/opt/ns-allinone-2.34/tk8.4.18/unix
NS=/opt/ns-allinone-2.34/ns-2.34/
NAM=/opt/ns-allinone-2.34/nam-1.14/
PATH=$PATH:$XGRAPH:$NS:$NAM

저장한 후 설정된 내용을 적용시킨다.

$ source ~/.bashrc

마지막으로 실행은 다음과 같다.

$ ns
%

위와 같은 내용이 눈에 보인다면 성공이다... 종료는 exit 명령을 사용한다.

CC2420 in-line security option

2010-07-21T01:06:00.001-07:00

Introduction

The CC2420 radio chip supports three types of in-line security modes, leveraging the same underlying 128-bit AES encryption:

Counter Mode Encryption (CTR)
Cipher Block Chaining Message Authentication Code (CBC-MAC)
Counter with CBC-MAC (CCM).

The CC2420 in-line security implementations add two new interfaces to the CC2420 radio stack in TinyOS 2.1: CC2420SecurityMode and CC2420Keys. The implementations are located in tos/chips/cc2420/security/ and the interfaces are located in tos/chips/cc2420/interfaces/. The design of the security implementation is based on the CC2420 specifications and the IEEE 802.15.4 2006 standards.

Transmitter Configuration

Makefile

Users intending to enable the security features MUST add the CC2420_HW_SECURITY flag in the Makefile.

CFLAGS+=-DCC2420_HW_SECURITY

Another point to note is the possible need for modifying the value of TOSH_DATA_LENGTH. Using different security options will add different amounts of additional overhead in the packet. For example, using the CBC-MAC authentication with a 16 byte MIC will require an additional 16 bytes in the payload portion of the message_t. While the security header is located in the cc2420_header_t, it takes up 6 additional bytes in the packet as well. The format of the security header can be found in tos/chips/cc2420/CC2420.h

Wiring (configuration file)

components new SecAMSenderC(AM_RADIO_COUNT_MSG) as AMSenderC;
components new AMReceiverC(AM_RADIO_COUNT_MSG);
components CC2420KeysC;
App.Receive -> AMReceiverC;
App.AMSend -> AMSenderC;
App.Packet -> AMSenderC;
App.CC2420SecurityMode -> AMSenderC;
App.CC2420Keys -> CC2420KeysC;

The AMSender interface MUST be wired to the SecAMSenderC component. The Packet interface is also provided by the SecAMSenderC and all packets that use the CC2420 in-line security features MUST be wired to this component. Note that the CC2420SecurityMode interface explained in the previous section is also provided by the SecAMSenderC component. The CC2420Key interface is provided by the CC2420KeyC component. The Receive interface can be wired as the case when no security is used because decryption happens transparently for the secured packets at the lower layers (below AM stack).

Implementation File

An array of 16 bytes SHOULD be set to store the desired key values. An example is shown below.

uint8_t key[16] = {0x98,0x67,0x7F,0xAF,0xD6,0xAD,0xB7,0x0C,0x59,0xE8,0xD9,0x47,0xC9,0x71,0x15,0x0F};

After the radio starts (SplitControl.startDone()), the following commands SHOULD be called to set the key values to a desired key register as explained above. The example below sets register 1 of the key registers (CC2420 offers registers 0 and 1) to a user specified key value shown above.

call CC2420Keys.setKey(1, key);

This call to the setKey command signals an event indicating the end of the key setting process.

event void CC2420Keys.setKeyDone(uint8_t keyNo, uint8_t* skey){}

This event is important for both the transmitting node. When this event is signaled, one of the following commands (provided by the CC2420SecurityMode interface) can be called for each packet transmission, with respect to the user-defined key values.

call CC2420SecurityMode.setCtr(msg, 1, 0);
call CC2420SecurityMode.setCbcMac(msg, 1, 0, 16);
call CC2420SecurityMode.setCcm(msg, 1, 0, 16);

For setCbcMac and setCcm, the last parameter is the size in bytes of the message authentication code. It can be 4, 8 or 16. Once the above steps are done,

call AMSend.send(msg, len);

can be called to send a packet just like any other packet transmissions.

Receiver Configuration

A receiver node that intends to enable the CC2420 Security features MUST add the CC2420_HW_SECURITY flag in the Makefile as well as the transmitter.

CFLAGS+=-DCC2420_HW_SECURITY

This enables all the decryption processes in the CC2420ReceiveP.nc file. Also, the receiver must have knowledge about the key values that a transmitter is using and SHOULD set the key registers with the user-desired keys before packets are exchanged. The example below sets register 1 of the key registers (CC2420 offers registers 0 and 1) to a user specified key value.

uint8_t key[16] = {0x98,0x67,0x7F,0xAF,0xD6,0xAD,0xB7,0x0C,0x59,0xE8,0xD9,0x47,0xC9,0x71,0x15,0x0F};
call CC2420Keys.setKey(1, key);

This call to the setKey command will signal an event indicating the end of the key setting process.

event void CC2420Keys.setKeyDone(uint8_t keyNo, uint8_t* skey){}

To use the CC2420Keys interface above, the following wiring MUST be done in the configuration file.

components CC2420KeysC;
App.CC2420Keys -> CC2420KeysC;

For the receiver, this event indicates that the radio is now ready to decrypt packets with the user-defined key values.

Examples

Sample implementations of applications that enable the CC2420 in-line security features (RadioCountToLeds and BaseStation) can be found in apps/tests/cc2420/TestSecurity/.

Contiki install and compile(for Linux)

2010-07-05T00:08:00.001-07:00

1. install

cvs –d:pserver:anonymous@contiki.cvs.sourceforge.net:/cvsroot/contiki login

cvs –z3 –d:pserver:anonymous@contiki.cvs.sourceforge.net:/cvsroot/contiki co contiki-2.x

다운로드는 /opt에 위치.(/opt/contiki-2.x)

2. compile

$cd /opt/contiki-2.x/examples/sky로 이동

$make sky-motelist 명령으로 현재 연결된 mote 정보 출력.

$make blink.upload 명령으로 컴파일 및 업로드.

주의! 이미 컴파일 및 업로드를 위한 패키지가 설치되어 있으므로 이 부분은 생략.

contiki overview…

2010-06-23T21:31:00.001-07:00

Contiki의 가장 큰 특징 중 하나는 동적 모듈 재할당 기능을 제공한다. 또한, Contiki는 기본적으로 TinyOS와 같이 이벤트 기반 모델을 지원하고 있다. protothread 를 통해 제한적 이기는 하지만 별도의 스택 예약 없이 멀티 스레드 같은 코드 간의 동기화를 제공한다. 하지만 지역 변수를 사용할 수 없고 지정된 구간에서만 블로킹(blocking)이 가능하다는 제약이 있어 완전한 멀티 스레드 센서 네트워크 운영체제라고는 할 수는 없다. 역시 센서 네트워크 노드용 운영체제를 타깃으로 만들어졌기 때문에 2kB의 RAM과 40kB 정도의 매우 작은 ROM을 가지고도 구동이 가능하다.
네트워크 스택으로는 uIP와 Rime를 지원하는데, uIP는 Contiki 개발자인 Adam Dunken이 제안한 8비트 MCU를 위한 TCP/IP 스택으로 임베디드 환경에서 인터넷을 통해 통신을 할 수 있도록 해준다. uIP는 현재 1.0버전까지 나와 있으며 IP,ICMP, UDP와 TCP 프로토콜을 지원한다. 일부 기능을 제거하고 느린 MCU 등을 고려하여 디자인되었기 때문에 delayed acknowledgment 기능을 제외하면 25,000kB/s 정도의 최대전송률을 가진다.
BSD socket 인터페이스와 유사한 protosocket 라이브러리를 제공하여 사용자가 쉽게 TCP 연결을사용할 수 있도록 하였으며, DNS resolver, SMTP e-mail sender, telnet server 등 다양한 애플리케이션을 함께 제공하고 있다. Rime은 저전력 통신을위해 구현된 멀티 홉 데이터 전송 프로토콜로 플러딩(flooding)을 통해 best-effort 브로드캐스팅을 지원하며, 컴파일 된 코드가 600byte 미만의 간단한 프로토콜이다.
Contiki 응용을 테스트해 볼 수 있는 Cooja라는 시뮬레이션 툴을 제공하며, 최근 릴리즈된 2.1버전에서는 노드의 에너지 상황을 실시간으로 모니터링 할 수 있는 기능을 지원한다.
현재 Contiki는 2010년 2월 16일 기준으로 2.4 ver. 이 릴리즈 되어 있으며 MAC, uIP/Rime, SensorAPI, COOJA/MSPSim, Micaz & Sensinode 8051/CC2430 등이 새롭게 지원되거나 확장되었다.

안드로이드 개발 환경 구축

2010-06-14T02:32:00.001-07:00

우분투 10.04-alternate 에서 안드로이드 개발 환경 셋팅

이미 이클립스가 설치되어 있으므로 이 부분은 제외

1. http://developer.android.com/sdk/index.html 에서 리눅스 패키지를 다운로드 한 후 원하는 위치에 압축을 해제

2. bashrc 파일에 환경 변수 추가

$vim ~/.bashrc

export PATH=${PATH}:~/opt/android-sdk-linux_86/tools

3. 이클립스 플러그인 설치(Eclipse 3.5 galileo)

add site : http://dl-ssl.google.com/android/eclipse/

4. Android SDK 경로 설정

eclipse – window – preferences

SDK Location : /opt/android-sdk-linux_86

5. Emulator 등록

$/opt/android-sdk-linux_86/tools

$./android

Avaliable Packages에서 최신 버전 API, SDK 를 인스톨한다.

5. 테스트를 위한 가상 디바이스 생성

Virtual Devices 선택 후 New…

Create new AVD 창이 나타나면 Name, Target 등을 지정하고 Create 한다.

T2 TOSSIM

2010-06-10T21:59:00.001-07:00

T2에서도 시뮬레이터 기능을 지원한다. 이는 센서 노드 어플리케이션이 올바르게 동작을 하는지 또는 오류가 발생할 여지가 없는지 등을 확인하기 위해 사용되지만 신뢰할 정도의 정확성이 요구되지는 않는다.

현재 T2에서는 micaz 플랫폼만을 지원하므로 telos 계열은 제외된다. 이 시뮬레이터를 이용하기 위해서는 avr toolchain이 필요하다. 하지만 TinyOS를 사용하는 사용자라면 이미 해당 환경이 갖추어져 있을 것이다. 또한, 시뮬레이션이 python을 이용하여 이루어지므로 python 관련 환경 설정도 갖추어져야 한다. 이 경우도 마찬가지로 TinyOS 를 사용하는 사용자의 경우라면 시뮬레이션을 위한 준비가 다 된 셈이다.

혹시라도 설정이 되어있지 않다면 대략 난감하므로 터미널을 이용하여 설정된 환경을 확인해 본다.

TinyOS env script file에 다음의 내용이 있는지 확인한다.

export PYTHONPATH=/opt/tinyos-2.x/support/sdk/python

없다면 추가한 후 환경 설정을 갱신한다.

다음으로 python –V 명령을 이용하여 python 버전을 확인해 본 후 sim.extra 파일에 명시된 버전과 일치하는지 확인한다.

$vim /opt/tinyos-2.x/support/make/sim.extra

만약 버전이 일치하지 않을 경우 현재 설치된 버전으로 수정한다.

또한, 옵션 추가를 위해 위와 같이 –shared 를 입력한 후 저장한다. 이제 시뮬레이션 실행을 위해 /opt/tinyos-2.x/apps/Blink로 이동한다.

$make micaz sim

위와 같이 컴파일하여 TOSSIM Library를 생성한다. BlinkC.nc 파일내에는 이미 디버그 메시지의 출력을 위한 dbg 함수가 작성되어 있다. 이 함수를 바탕으로 python을 실행하여 시뮬레이트 할 수 있다.

make pc error

2010-06-09T02:23:00.001-07:00

어떤 이유에서인지 tinyos 시뮬레이션을 위한 어플리케이션 컴파일이 제대로 이루어지지 않는 문제가 발생함.

tinyos-help를 뒤져봐도 명확한 해결책이 나오지 않아 나름 정확하지는 않지만 gcc 문제(version)로 판단하여 현재 문제 해결 하였음.

TinyOS installation on xubuntu 10.04 alternate

2010-06-01T02:26:00.001-07:00

* update repository
$sudo apt-get update

* add packages
$sudo apt-get install vim cvs subversion autoconf automake1.9
$sudo apt-get install g++ gperf swig graphviz alien

* add tinyos repository
$vim /etc/apt/sources.list
deb http://tinyos.stanford.edu/tinyos/dists/ubuntu lucid main
$sudo apt-get update
$sudo apt-get install msp430-tinyos avr-tinyos
$sudo apt-get install tinyos-tools

* nesc compiler downgrade
nesc-1.2.8a-1.i386.rpm –> deb file converter
$sudo alien –c nesc-1.2.8a-1.i386.rmp
$sudo dpkg –i nesc-1.2.8a-1.i386.deb

* tinyos cvs download
$cvs -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos login
$cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co tinyos-1.x tinyos-2.x tinyos-2.x-contrib

* tinyos env. script file(tinyos-1.x, tinyos-2.x)
TinyOS-1.x --------------------------------------------------------
unset CLASSPATH
export TOSROOT=/opt/tinyos-1.x
export TOSDIR=$TOSROOT/tos
export CLASSPATH=$TOSROOT/tools/java
export MAKERULES=$TOSROOT/tools/make/Makerules
echo "--------------------------------"
echo "Currently, TinyOS-1.x env."
echo "--------------------------------"
export JAVA_HOME=/usr/lib/jvm/java-6-openjdk
export JDKROOT=$JAVA_HOME
export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH
export CLASSPATH=$CLASSPATH:.
export MSPGCCROOT=/usr/msp430
export PATH=$MSPGCCROOT/bin:$PATH
---------------------------------------------------------------------
TinyOS-2.x --------------------------------------------------------
unset CLASSPATH
export TOSROOT=/opt/tinyos-2.x
export TOSDIR=$TOSROOT/tos
export CLASSPATH=$TOSROOT/support/sdk/java/tinyos.jar:.
export MAKERULES=$TOSROOT/support/make/Makerules
echo "--------------------------------"
echo "Currently, TinyOS-2.x env."
echo "--------------------------------"
export JAVA_HOME=/usr/lib/jvm/java-6-openjdk
export JDKROOT=$JAVA_HOME
export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH
export CLASSPATH=$CLASSPATH:.
export MSPGCCROOT=/usr/msp430
export PATH=$MSPGCCROOT/bin:$PATH
---------------------------------------------------------------------

* serial communication(RXTX)
download site http://www.rxtx.org/
$JAVA_HOME/jre/lib/i386
librxtxParallel.so / librxtxSerial.so
$JAVA_HOME/jre/lib/ext
RXTXComm.jar
tinyos java application source file modify
$cd /opt/tinyos-1.x/tools/java
$grep -rn javax.comm *
import javax.comm.*; –> import gnu.io.*;

$cd /opt/tinyos-1.x/tools/java
$./javapath
$tos-install-jni
$make

* Eclipse
$sudo apt-get install eclipse
/usr/lib/eclipse
excute eclipse - Help - Install New Software
add site http://download.eclipse.org/releases/galileo - Modeling download
nescdt plugin 및 yeti2 plugin 설치
tip : 이클립스에서 nescdt 플러그인을 설치하고 빌드하기 위해서는 tinyos 환경 설정이 우선 되어야 한다.
/etc/profile.d 에 tinyos.sh 파일 생성
$vim /etc/profile.d/tinyos.sh
----------------------------------------------------------------------
#Java
export JAVA_HOME=/usr/lib/jvm/java-6-openjdk
export JDKROOT=$JAVA_HOME
export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH
export CLASSPATH=$CLASSPATH:.

#Java can find libtoscomm.so and libgetenv.so
export LD_LIBRARY_PATH=$JDKROOT/jre/lib/i386

#Conditional environmental setup for TinyOS-1.x
export TOSROOT=/opt/tinyos-1.x
export TOSDIR=$TOSROOT/tos
export MAKERULES=$TOSROOT/tools/make/Makerules
export CLASSPATH=$CLASSPATH:$TOSROOT/tools/java

# Finally set the path for the MSPGCCROOT
#export MSPGCCROOT=/usr/msp430
#export PATH="$MSPGCCROOT/bin:$PATH"
---------------------------------------------------------------------------

* LAPM, Samba, SSH

T2에서의 ADC Mapping

2010-05-13T23:44:00.001-07:00

* Configuration *
generic configuration TestC() {
provides interface DeviceMetadata;
provides interface Read<uint16_t> as Test;
provides interface ReadStream<uint16_t>;
}
implementation {
components new AdcReadClientC();
Test = ADCReadClientC;
components new AdcReadStreamClientC();
ReadStream = AdcReadStreamClientC;
components TestP;
DeviceMetadata = TestP;
AdcReadClientC.AdcConfigure –> TestP;
AdcReadStreamClientC.AdcConfigure –> TestP;
}

* Module *
#include “Msp430Adc12.h”
module TestP {
provides interface DeviceMetadata;
provides interface AdcConfigure<const msp430adc12_channel_config_t *>
}
implementation {
msp430adc12_channel_config_t config = {
    inch:INPUT_CHANNEL_A2,
    sref:REFERENCE_VREFplus_AVss,
    ref2_5v:REFVOLT_LEVEL_1_5,
    adc12ssel:SHT_SOURCE_ACLK,
    adc12div:SHT_CLOCK_DIV_1,
    sht:SAMPLE_HOLD_4_CYCLES,
    sampcon_ssel:SAMPCON_SOURCE_SMCLK,
    sampcon_id:SAMPCON_CLOCK_DIV_1
};
command uint8_t DeviceMetadata.getSignificantBits() {
    return 12;
}
async command const msp430adc12_channel_config_t * AdcConfigure.getConfiguration() {
    return &config;
}
}

위와 같이 컴포넌트를 작성하여 최상위 어플리케이션에서 wiring을 통해 사용하면 된다.

TinyOS에서 CC2420 동작 원리

2010-05-13T22:00:00.001-07:00

현재 IEEE 802.15.4 프로토콜의 MAC layer 표준에 상응하는 2.4GHz대역의 CC2420이 센서 네트워크 플랫폼의 radio chip으로 많이 사용되고 있다. TinyOS 에도 CC2420에 대한 부분이 포함되어 있으며 이는 CC2420을 동작하게 하는 드라이버 부분과 backoff 및 CCA 알고리즘이 추가 구현되어 있다.
이 문서는 TinyOS에서 구현된 CC2420의 동작 원리를 분석하여, RF 메커니즘의 이해를 돕고자 하는데 그 의의가 있다.

1. IEEE 802.15.4 프로토콜

IEEE 802.15.4 의 standard feature는 다음과 같다.
The IEEE 802.15.4-2003 standard
• Data rates of 250 kbps, 40 kbps, and 20 kbps.
• Two addressing modes; 16-bit short and 64-bit IEEE addressing.
• Support for critical latency devices, such as joysticks.
• CSMA-CA channel access.
• Automatic network establishment by the coordinator.
• Fully handshaked protocol for transfer reliability.
• Power management to ensure low power consumption.
• 16 channels in the 2.4GHz ISM band, 10 channels in the 915MHz I and one
channel in the 868MHz band.
또한, CC2420의 간단한 specification을 보면 다음과 같다.
The IEEE 802.15.4-2003 standard
• true single-chip 2.4 GHz (16 channels in ISM band)
• Max data rate : 250Kbps
• Low current consumption (RX: 19.7 mA, TX: 17.4 mA)
위와 같이, CC2420은 IEEE 802.15.4 MAC hardware를 지원 가능하다. CSMA-CA에 대한 부분은 tinyos에서 B-MAC이란 MAC protocol을 사용해서 보완하고 있다.

2. CC2420 driver

CC2420은 MCU와 4-wire SPI-bus configuration interface (SI, SO, SCLK and CSn). 로 연결되어 SPI통신을 통한 동작을 기본으로 한다.

CSN은 SPI Chip select로, SPI 통신의 enable/disable을 담당한다. 일반적으로 low상태일 때, enable이 되고, High 일 때, disable이 된다. SI는 SPI Bus의 Input으로 사용되고, SO는 SPI Bus의 Output으로 사용된다. SCLK는 SPI Bus의 serial clock으로 사용된다.
atmega에서는 SPI를 컨트롤하는 레지스터를 갖고 있어서, 간단한 설정만으로도 SPI통신이 가능하다. 하지만 msp430 계열은 SPI를 컨트롤하는 레지스터가 없기 때문에, UART를 SPI mode로 변경하여 사용한다. TinyOS에서는 SPI mode의 초기화를 각 architectre별로 다음과 같이 구현하고 있다.
------------------------------------------------------------------------------
Atmega - 128

TOSH_MAKE_SPI_SCK_OUTPUT();
TOSH_MAKE_MISO_INPUT(); // miso
TOSH_MAKE_MOSI_OUTPUT(); // mosi
sbi (SPSR, SPI2X); // Double speed spi clock
sbi(SPCR, MSTR); // Set master mode
cbi(SPCR, CPOL); // Set proper polarity...
cbi(SPCR, CPHA); // ...and phase
cbi(SPCR, SPR1); // set clock, fosc/2 (~3.6 Mhz)
cbi(SPCR, SPR0);
// sbi(SPCR, SPIE); // enable spi port interrupt
sbi(SPCR, SPE); // enable spi port
------------------------------------------------------------------------------
------------------------------------------------------------------------------
MSP430

async command void USARTControl.setModeSPI() {
//check if we are already in SPI mode
if(call USARTControl.getMode() == USART_SPI)
    return;
call USARTControl.disableUART();
call USARTControl.disableI2C();
atomic {
    TOSH_SEL_SIMO1_MODFUNC();
    TOSH_SEL_SOMI1_MODFUNC();
    TOSH_SEL_UCLK1_MODFUNC();
    IE2 &= ~(UTXIE1 | URXIE1); // interrupt disable
    U1CTL |= SWRST;
    U1CTL |= CHAR | SYNC | MM; // 8-bit char, spi-mode, USART as master
    U1CTL &= ~(0x20); U1TCTL = STC ; // 3-pin
    U1TCTL |= CKPH; // half-cycle delayed UCLK
    if (l_ssel & 0x80) {
      U1TCTL &= ~(SSEL_0 | SSEL_1 | SSEL_2 | SSEL_3);
      U1TCTL |= (l_ssel & 0x7F);
    }
    else {
      U1TCTL &= ~(SSEL_0 | SSEL_1 | SSEL_2 | SSEL_3);
      U1TCTL |= SSEL_SMCLK; // use SMCLK, assuming 1MHz
    }
    if (l_br != 0) {
      U1BR0 = l_br & 0x0FF;
      U1BR1 = (l_br >> 8) & 0x0FF;
    }
    else {
      U1BR0 = 0x02; // as fast as possible
      U1BR1 = 0x00;
    }
    U1MCTL = 0;
    ME2 &= ~(UTXE1 | URXE1); //USART UART module disable
    ME2 |= USPIE1; // USART SPI module enable
    U1CTL &= ~SWRST;
    IFG2 &= ~(UTXIFG1 | URXIFG1);
    IE2 &= ~(UTXIE1 | URXIE1); // interrupt disabled
  }
  return;
}
------------------------------------------------------------------------------
위에서 보듯이, atmega는 6~7번의 레지스터 세팅으로 SPI 통신을 초기화 할 수 있지만, msp430은 일반적인 UART 설정을 기본으로 초기화한다. 실제로, 일반 UART 초기화와의 차이점은 SPI module disable/enable을 제어하는 레지스터의 설정밖에 없다.(USPIEx) 초기화 후에, 간단한 SPI read/write function을 기본으로 작성된 여러가지 함수를 이용해서 CC2420을 제어하게 된다. 몇몇 중요 함수들의 예는 다음과 같다.

HPLCC2420.cmd(uint8_t addr) :
• CC2420으로 하나의 command를 보내고, 수신된 status 값을 리턴한다.
HPLCC2420.read(uint8_t addr) :
• CC2420으로부터 16-bit 레지스터 값을 받아온다.
HPLCC2420FIFO.readRXFIFO (uint8_t length, uint8_t *data) :
• RX FIFO 큐로부터 length만큼 값을 받아오고, data에 저장한다.
HPLCC2420FIFO.writeTXFIFO(uint8_t length, uint8_t *data) :
• data에 저장된 length만큼의 데이터를 TX FIFO에 write한다.

이제 이 함수들을 어떻게 사용하여 CC2420을 제어하는지 살펴보자.
CC2420의 드라이버 및 B-MAC이 구현된 부분은 /opt/tinyos-1.x/tos/lib/CC2420Radio 이다. 각 architecture별로 구현된 SPI/SPI응용 함수들을 이용하여 CC2420의 제어가 가능하다.
드라이버에서 가장 처음에 하는 일은 CC2420의 power on, reset toggle 을 하는 것이다.
------------------------------------------------------------------------------
//turn on power
call CC2420Control.VREFOn();
// toggle reset
TOSH_CLR_CC_RSTN_PIN();TOSH_wait();
TOSH_SET_CC_RSTN_PIN();TOSH_wait();
------------------------------------------------------------------------------
그 다음은 CC2420의 crystal을 enable시킴으로서, CC2420의 동작을 위한 최소한의 하드웨어 설정을 마친다. CC2420으로 CC2420_SXOSCON(0x01)이란 command를 보내면 crystal이 동작하게 된다.
------------------------------------------------------------------------------
async command result_t CC2420Control.OscillatorOn() {
......
status = call HPLChipcon.cmd(CC2420_SXOSCON); //turn-on crystal
......
------------------------------------------------------------------------------
CC2420의 send 모드는 크게 두가지로 나눌 수 있다. 채널이 clear될 때까지 기다리다가 clear되는 순간 전송을 하는 방식과, 채널의 상태에 관계없이 전송을 하는 방식이다.
------------------------------------------------------------------------------
async command result_t CC2420Control.TxMode() {
call HPLChipcon.cmd(CC2420_STXON);
return SUCCESS;
}
//Shift the CC2420 Radio into transmit mode when the next clear channel
is detected.
async command result_t CC2420Control.TxModeOnCCA() {
call HPLChipcon.cmd(CC2420_STXONCCA);
return SUCCESS;
}
------------------------------------------------------------------------------
CC2420의 receive모드는 다음과 같다
------------------------------------------------------------------------------
async command result_t CC2420Control.RxMode() {
call HPLChipcon.cmd(CC2420_SRXON);
return SUCCESS;
}
------------------------------------------------------------------------------
CC2420Control 에 모듈의 초기화, TX/RX 모드 함수, RF power및 frequency 설정을 하는 기본 함수들이 포함되어 있다면, CC2420Radio는 송/수신에 직접적이면서 복잡한 함수들이 포함되어 있다. 송신 함수는 sendPacket(), startSend(), tryToSend()함수로 구현되어 있다. startSend는 말그대로 송신을 시작하는 함수로, TXFIFO에 송신할 패킷을 length만큼 write하게 된다. 이 함수가 종료되면 패킷들이 FIFO에서 송출되기를 기다린다.
------------------------------------------------------------------------------
task void startSend() {
// flush the tx fifo of stale data
if (!(call HPLChipcon.cmd(CC2420_SFLUSHTX))) {
sendFailed();
return;
}
// write the txbuf data to the TXFIFO
if (!(call HPLChipconFIFO.writeTXFIFO(txlength+1,(uint8_t*)txbufptr))) {
sendFailed();
return;
}
}
------------------------------------------------------------------------------
sendPacket은 RF로 패킷을 보내는 함수이다. tryToSend에서 call되어 사용되어 지며, 채널이 clear되면 전송되는 방식을 사용한다.
------------------------------------------------------------------------------
void sendPacket() {
uint8_t status;
call HPLChipcon.cmd(CC2420_STXONCCA);
status = call HPLChipcon.cmd(CC2420_SNOP);
……..
}
------------------------------------------------------------------------------
tryToSend는 CCA핀을 read했을 때, High상태라면, 즉 채널이 clear하다면 sendPacket을 call하여 패킷을 전송하고, 채널이 사용중이라면 normal operation을 계속해서 수행한다.
------------------------------------------------------------------------------
void tryToSend() {
…………..
// if a FIFO overflow occurs or if the data length is invalid, flush
// the RXFIFO to get back to a normal state.
if ((!TOSH_READ_CC_FIFO_PIN() && !TOSH_READ_CC_FIFOP_PIN())) {
flushRXFIFO();
}
if (TOSH_READ_RADIO_CCA_PIN()) {
atomic stateRadio = TX_STATE;
sendPacket();
}
else {
// if we tried a bunch of times, the radio may be in a bad state
// flushing the RXFIFO returns the radio to a non-overflow state
// and it continue normal operation (and thus send our packet)
if (countRetry-- <= 0) {
flushRXFIFO();
countRetry = MAX_SEND_TRIES;
if (!post startSend())
sendFailed();
return;
}
……………
}
------------------------------------------------------------------------------
tryToSend는 startSend가 종료되는 시점에 실행이 된다. 즉 startSend에서 TXFIFO를 채우면 HPLChipconFIFO.TXFIFODone()이 실행되고, 이 함수안에서 tryToSend를 실행하게 되어, FIFO에 write된 패킷이 무선으로 전송된다.
rxMode로 설정되어 있을 때, 같은 주파수대의 패킷이 들어오면, FIFOP에 interrupt가 발생한다. Interrupt가 발생했을 때, FIFOP.fired 라는 인터럽트 함수가 실행하게 되고, 이는 수신된 패킷을 RXFIFO로 write한다. RXFIFO로 값이 모두 들어오면, HPLChipconFIFO.RXFIFODone()라는 함수가 실행된다.
------------------------------------------------------------------------------
async event result_t FIFOP.fired() {
…………..
/** Check for RXFIFO overflow **/
if (!TOSH_READ_CC_FIFO_PIN()){
flushRXFIFO();
return SUCCESS;
}
atomic {
if (post delayedRXFIFOtask()) {
call FIFOP.disable();
}
else {
flushRXFIFO();
}
}
// return SUCCESS to keep FIFOP events occurring
return SUCCESS;
}
------------------------------------------------------------------------------
HPLChipconFIFO.RXFIFODone()이 실행되면 데이터 예외처리를 거쳐서 정상적인 length의 패킷을 rxbufptr 버퍼에 저장한다. rxbufptr에 할당이 되는 *data는 TOS_MsgPtr 의 구조체 변수 크기에 맞게 바이트 단위로 parsing되서 저장된다. length가 길면 패킷은 버려지고, 짧으면 crc, RSSI, LQI값을 맟춰서 할당한다.
------------------------------------------------------------------------------
async event result_t HPLChipconFIFO.RXFIFODone(uint8_t length, uint8_t *data){
…………….
rxbufptr = (TOS_MsgPtr)data;
……………
if (rxbufptr->length > TOSH_DATA_LENGTH) {
flushRXFIFO();
atomic bPacketReceiving = FALSE;
return SUCCESS;
}
// adjust destination to the right byte order
rxbufptr->addr = fromLSB16(rxbufptr->addr);
// if the length is shorter, we have to move the CRC bytes
rxbufptr->crc = data[length-1] >> 7;
// put in RSSI
rxbufptr->strength = data[length-2];
// put in LQI
rxbufptr->lqi = data[length-1] & 0x7F;
……………
}
------------------------------------------------------------------------------
지금까지 TinyOS에서의 CC2420이 마이크로 컨트롤러와 어떻게 통신을 하고 동작을 하는지를 알아보았다. 물론 위의 설명은 CC2420의 동작원리를 충분히 이해하기엔 너무 개략적이고 의미 중심적이다. 따라서 윗글은 CC2420소스를 처음 접하여 분석하고자 하는 분에게 소스의 전반적인 구성을 이해하는데 참조할 수 있는 자료라 할 수 있겠다.

- hybus -

Dissemination

2010-05-11T02:18:00.001-07:00

Dissemination 프로토콜은 네트워크 전체에 동일한 데이터를 전달하고 이들의 일관성을 유지시키는 서비스이다. 이를 위해 각 노드는 이 데이터의 복사본을 저장하며, 나중에 해당 데이터의 값이 변경될 경우 이를 알리고, 네트워크 전체에 걸쳐 이 데이터가 일관된 값을 갖게 될 때까지 패킷들을 교환한다. 초기에는 대부분의 노드들이 이전 값(stale value)을 갖는 불안정한 상태를 갖겠지만, 이 과정을 통해 시간이 지나면서 최근 값(up-to-data value)을 갖도록 네트워크 전체가 수렴한다.

이 기법은 패킷 손실이나, 일시적인 통신 단절등에 상당히 잘 견디며, 단순히 패킷을 노드 간에 반복 전달하는데 그치는 플러딩(flooding) 방식과는 달리 Dissemination 기법은 네트워크에 연결되어 있는 모든 노드들이 궁극적으로는 일관된 값을 갖도록 보장한다. 전송할 데이터의 크기에 따라 이 프로토콜의 성능은 크게 다르며, 수십 KB의 데이터를 dissemination하는 것은 몇 Bytes를 전송하는 경우와는 약간 다른 프로토콜을 요구하는데, 자세히 살펴보면 근본적으로는 매우 유사하다. Dissemination 프로토콜을 제어와 데이터 트래픽으로 나눠보면, 데이터 트래픽 프로토콜은 데이터의 크기에 밀접한 관련이 있지만, 제어 트래픽 프로토콜은 동일하거나 비슷한 경향을 보인다. 예를 들어, UC Berkely에서 개발한 Deluge 바이너리 프로그래밍 서비스는 바이너리(실행 프로그램)에 대한 메타 정보를 전파한다. 이 과정에서 노드들이 자신들이 갖고 있는 바이너리의 정보가 전달받은 정보와 다르면, 그들은 자신의 노드에 있는 바이너리가 잘못되었거나 새로운 바이너리가 필요하다는 것을 알 수 있다.

이 기법에서는 어떤 노드라도 네트워크에게 자신이 새로운 값을 생성했다고 알림으로 네트워크 전체가 일관된 상태로 수렴하도록 요구할 수 있다. 그리고, 모든 노드들이 이 값에 동의하면 네트워크 전체에 걸쳐 동일한 값으로 수렴한다. 이와 같은 방법으로 작은 데이터들을 Dissemination 할 수 있다면 센서 네트워크의 중요한 기능을 담당할 수 있다. 예를 들면, 작은 프로그램을 네트워크에 전달하거나 네트워크의 재구성, 질의 또는 명령, 재프로그램등을 지원할 수 있다.

Collection

2010-05-11T02:14:00.001-07:00

Collection은 센서 네트워크의 각 노드에서 발생한 데이터들을 PC 호스트 등의 베이스 스테이션으로 전달하는 기능을 수행한다. 이 경우 일반적으로 베이스 스테이션에 연결된 싱크 노드를 루트로 갖는 Collection Tree를 구성하며, 하나의 네트워크에서 이와 같은 트리는 여러 개 생성될 수 있다.

TinyOS에서는 트리를 구성하기 위해 CTP(Collection Tree Protocol)을 사용한다. 네트워크에서 임의의 노드가 자신이 루트라고 알리면 네트워크의 노드들은 루트 노드를 중심으로 라우팅 트리들을 구성한다. 이 때 각 노드들은 루트 노드로 향하는 경로를 설정하기 위해 라우팅 기울기(routing gradient)를 계산한다. 즉, 각 노드는 싱크 노드와의 근접성을 측정하고, 이를 바탕으로 싱크 노드에 최대한 근접하는 링크를 선택하며 점진적으로 경로를 설정해 간다.

CTP는 라우팅 기울기로 ETX(Expected transmissions) 값을 사용한다. 루트 노드의 ETX 값은 0으로 정의하며, 어떤 노드의 ETX 값은 자신의 부모 노드가 갖는 ETX 값과 해당 노드에서 부모 노드로의 링크가 갖는 ETX 값을 더한 값을 갖는다. 이와 같은 상황에서 임의의 노드는 루트 노드로의 경로 설정 시에 가장 낮은 ETX 값을 갖는 링크를 선택하고, 이 링크에 연결된 노드를 부모 노드로 기록하며, 이 과정이 루트 노드를 시작으로 전체 네트워크에 이르기까지 반복된다.

위 그림은 CTP를 구성하는 컴포넌트들을 나타내고 있으며, 이 가운데 CtpP 컴포넌트가 핵심 기능을 제공한다. 특히 CtpP는 한 홉(Hop) 간 ETX 값을 측정하기 위해 LinkEstimatorP 컴포넌트를 포함하며, 이 값을 이용해 다음 라우팅 링크를 결정하기 위해 CtpRoutingEngineP 컴포넌트를 사용한다. 마지막으로 라우팅 링크로의 패킷 전송을 위해 CtpForwardingEngineP 컴포넌트가 사용된다. 보다 상세한 수준의 컴포넌트는 TinyOS에서 제공하는 docs 유틸리티를 활용하여 컴포넌트들의 연결 구조를 파악할 수 있다.

이와 같은 구성으로 CTP가 구현되어 있으며 위에서 설명한 동작방식을 통해 센서 네트워크 내의 임의의 노드가 데이터를 생성하면, 자신의 부모 노드를 향해 데이터를 전달(forwarding)한다. 이를 통해 루트는 자신의 하위에 있는 모든 노드로부터 발생한 데이터를 수집하는 역할을 담당한다.

네트워크가 여러 루트를 가졌을 때, Tree 형태의 forest를 구성하게 된다.

하지만 단순한 Colletcion 프로토콜은 여러 문제에 직면한다. 가령 전달 경로에 루프(loop)가 생기거나, 데이터의 중복 전송 문제 등이 발생할 수 있다. 이 때문에 일반적으로 분산된 트리를 구성하는 알고리즘에 제한을 둔다. 다음은 이와 같은 알고리즘이 해결해야 할 과제들이다.

▪Loop detection
자손 중 하나를 부모 노드로 선택하는 상황 검출

▪Duplicate suppression
네트워크에서 패킷의 중복 전송 원인이 되는 ACK의 손실을 탐지

▪Link estimation
한 홉간의 이웃과의 Link quality를 측정

▪Self-interference
다음 패킷의 경로를 이전 패킷들과 간섭이 생기는 경로로 라우팅하는 것을 방지

리눅스 권한 설정

2010-05-10T18:59:00.001-07:00

리눅스에서 권한 설정은 chmod(change mode) 명령을 이용한다.

리눅스는 사용자 번호(UID)와 그룹번호(GID)를 가지고 모든 사용자를 구분하는데, 파일은 그것을 생성한 소유자에게 속해 있으며 이 명령을 통해 폴더 및 파일에 대한 접근 권한을 줄 수 있다.

chmod [option] octal-mode file(s)
chmod [option] symbolic-mode file(s)

option

-R 서브 디렉토리의 파일까지 재귀적으로 실행
-f 자기 소유가 아닌 파일에 변경 시도
-v 변경되는 모드에 대해 출력

octal-mode

symbolic-mode

참고로 chmod –R 777 /share * 명령을 이용하면 share 폴더에 있는 하위 폴더의 파일내용까지도 파일소유자, 그룹, 기타 사용자까지 모두 읽기, 쓰기, 실행을 허용한다는 것이다.

TOSH_uwait();

2010-05-02T18:49:00.001-07:00

TOSH_uwait();에 포함되는 단위는 usec(microsec) 이다.
참고로 TOSH_uwait(10000); == 10ms == 0.01sec 가 된다.

이 함수는 /opt/tinyos-1.x/tos/platform/msp430/msp430hardware.h 에 정의 되어 있다.

Install TinyOS and the 8051wg platforms

2010-04-29T18:42:00.001-07:00

In order to use this port you need the following prerequisites. The tool chain assumes that the compiler and tools are installed in particular locations and that you setup your environment variables as described below.

A TinyOS 2 installation, in Windows using Cygwin or natively in Linux or similar. Inline is only supported for x86 platforms.
A 8051 compiler
1. Keil PK51 (any version)
2. IAR Workbench version 7 or later
3. SDCC version 2.9.0 or later
A copy of the port from TinyOS-contrib
Hardware programming tools for you particular chip (eg. cc2430)

1. TinyOS 2 install

TinyOS 2 must be installed separate from this port, either in Windows through Cygwin or natively in Linux (or similar). TinyOS version 2.1. and NescC version 1.3.0 are supported presently.

1.1 Windows trough Cygwin

For Cygwin or Linux users follow the instructions from docs.tinyos.net. For Cygwin users remember to install the packages rpm and gcc-mingw. As a bare minimum you need to install the nescc, tinyos-tools, tinyos-deputy and tinyos packages.


$ rpm -i nesc-1.3.0-1.cygwin.i386.rmp
$ rpm -i tinyos-tools-1.3.0-1.cygwin.i386.rpm
$ rpm -i tinyos-deputy-1.1-1.cygwin.i386.rpm
$ rpm -i tinyos-2.1.0-1.cygwin.noarch.rpm

1.2 Windows trough virtual machine

Alternatively Windows users may want to run the Linux through a virtual machine such as Virtual PC or VMWare Server. XubunTOS provides an install image with TinyOS pre-installed. XubunTOS can also be downloaded ad a ready-to-run virtual machine here.

1.3 Linux native install

Linux (and similar) are supported natively, follow the appropriate instructions on docs.tinyos.net your distribution. For example, the installation of TinyOS 2.1 on Ubuntu, is described here.

2. 8051 compiler

To compile programs using this port an 8051 C-compiler is required. We recommend Keil PK51 - this port is written and tested using the Keil compiler. In addition IAR or SDCC may be used, but these are not tested. There are numerous other companies providing compilers that might or might not work, but additional compilers are not supported through the tool chain. Which compiler to used is selected using the environment variable MCS51_COMPILER (see Section 3).
Keil and IAR are Windows only compilers, to use them in Linux they are run through Wine. Each compiler is installed in a separate Wine directory (eg. .wine.keil for Keil) to avoid interference. First install wine and create the appropriate wine directory (using Ubunto or Xubuntos):


apt-get install wine
env WINEPREFIX=~/.wine.keil wineprefixcreate

2.1 Installing Keil PK51

Keil PK51 is a commercial 8051 compiler that can be purchased from http://www.keil.com/. A trial version is available with a 2 KiB code size limit on the compiled binaries. For either Cygwin or Wine install Keil in the default location (C:Keil).

2.1.1 Linux

The tool chain assumes Keil is install using the Wine environment in the directory named ~/.wine.keil. Run the Keil installer using Wine (either from the provided CD-rom or downloaded binary):


WINEPREFIX=$(HOME)/.wine.keil wine C51V809A.EXE

To enter your license code start the uVision development environment and enter it the same way you would in Linux:


WINEPREFIX=~/.wine.keil wine "C:\Keil\UV3\Uv3.exe"

2.1.2 Windows

Simply install the compiler using the appropriate installer.

2.2 Installing SDCC

SDCC is a free, open souce C compiler with native Linux and Windows support. SDCC versions 2.6 and greater provide native inline support. We have not been able to successfully compile a TinyOS application using this inliner. We recommend using the stand alone inline tool provided with this TinyOS port.

2.2.1 Linux

To install sdcc using Debian, Ubuntu or XUbunTOS run the following command:


apt-get install sdcc sdcc-libraries

2.2.2 Windows

Download and install the compiler from http://sdcc.sourceforge.net/. Answer yes to the question "Add to path".

2.3 Installing IAR

Iar is a commercial compiler for Windows. It has a 30 day evaluation is available here. In either Windows or Linux set the path of the compiler in the environment variable MCS51_IAR_PATH, for example the default is:


export MCS51_IAR_PATH=Program\ Files/IAR\ Systems/Embedded\ Workbench\ 4.0\ Evaluation\ version/common/bin/

2.3.1 Linux

Install the compiler using Wine:


env WINEPREFIX=~/.wine.iar wine EW8051-EV-730B.exe

2.3.1 Windows

Simply install the compiler using the native installer.

3. 8051 port from TinyOS-contrib

The code is located in the TinyOS-2.x-contrib section and is downloaded separately from TinyOS. See download for more.

3.1 8051 port directory

The the archive above contains the code in a directoryh namednamed tinyos-2.x-contrib/diku. This directory must be places in par particular location (or speficfied in the variable below).
By placing the directory in the following locations the build system will automatically be able to locate the port

For cygwin c:\cygwin\opt
Linux /opt

3.2 Environment variables

The ports need a few environment variables in addition to the default TinyOS variables. These variables enable the TinyOS make system to locate the Make rules and the source files.

TOSDIR (location of T2 tree)
MAKERULES (location of T2 Makerules)
TOSMAKE_PATH list of directories to search for .target files (separated by spac"
CONTRIBROOT (root of the contrib directory)

In addition a few optional variables control and select which compiler to use:

MCS51_COMPILER select compiler one of (keil, sdcc or iar)
MCS51_WINE_IAR_PATH wine directory for Keil (default ~/.wine.keil)
MCS51_WINE_KEIL_PATH wine directory for IAR (default ~/.wine.iar)
MCS51_IAR_PATH Path to IAR compiler

An example script is provided as diku/env which sets up these variables, to include them run the following command (for bash and zsh):


cd tinyos-2.x-contrib
source diku/env

4. Hardware programming tools.

In order to transfer the compiled binary to the chip you need the chip or platform maintainer's tool for this purpose.

Texas Instrumenst (ChipCon) Development Kit: ChipCon Flash Programmer. The programmer is only available for Windows. Other users will have to dual boot or run in an emulator. http://focus.ti.com/docs/toolsw/folders/print/cc2430dk.html#supportsoftware
SiLabs 8051: SiLabs provides a Windows GUI programmer. For Linux (and similar) the ec2drv project provides a command line programmer
nRF24e1: Nordic VSLI provides a programmer for Windows
Sensinode Nano: http://www.sensinode.com/top/information.php?info_id=10

5. Test the setup

With the above prerequisites your setup should be ready to go. To test the setup compile one of the example applications:


cd mcs51/apps/BlinkNoTimer
make cc2430em

If all goes well you should see the following message:


...
GENERATING INTEL HEX FILE: app.hex
compiled BlinkNoTimerTaskAppC to a cc2430em binary
Code size of app.o
MODULE INFORMATION:   STATIC OVERLAYABLE
CODE SIZE        =    635    ----
CONSTANT SIZE    =   ----    ----
XDATA SIZE       =      4       9
PDATA SIZE       =   ----    ----
DATA SIZE        =   ----    ----
IDATA SIZE       =   ----    ----
BIT SIZE         =   ----    ----
Total sizes
Program Size: data=9.0 xdata=10 const=0 code=694

6. Trouble shooting

In case of problems start your setup using the mcs51_env_check.sh script


./diku/mcs51/support/make/mcs51/mcs51_env_check.sh -v

MSP430Fxx series SPI Communication.

2010-04-21T02:41:00.000-07:00

MSP430Fx에서 SPI 통신을 하기 위해서는 어떻게 해야 할까...

먼저 하드웨어를 살펴보자.
MSP430은 USART0과 USART1 이 존재한다.
USART0은 uart, i2c, spi 가 가능하며, USART1은 uart, spi가 가능하다.
여기서 USART0은 CC2420과 연결되어 무선 통신에 쓰이므로 무선 통신을 사용하기 위해서 패스하고, USART1을 이용하여 spi를 사용하도록 한다.
여기서 MSP430의 결점(?)이 드러나기 시작한다. MSP430 family는 SPI를 직접 컨트롤 할 수 있는 레지스터가 없다.
앞서 언급한 듯이 USART1은 uart와 spi 통신이 가능한데, 두 가지 통신을 한꺼번에 하지 못한다.
즉, 공유자원으로 사용한다는 것이다. uart 통신을 하고자 한다면 uart 모드로 변경해야 하고, spi 통신을 하고자 한다면 spi 모드로 변경해서 사용해야한다.
둘 다 사용하고자 한다면 소프트웨어적으로 스케줄링해서 사용할 수 있다.
tinyos에서는 이를 어떻게 해야 하는지는 뒤에서 언급하도록 한다.

USART1을 SPI 모드로 사용할 경우 p.5.1 ~ p5.3이 쓰인다.
p.5.1은 마스터 모드인 경우 데이터 출력, 슬레이브인 경우 데이터 입력이 가능하다. (SIMO1)
p.5.2는 반대로 마스터 모드인 경우 데이터 입력, 슬레이브인 경우 데이터 출력이 가능하다. (SOMI1)
p.5.3의 경우 마스터인 경우 시리얼 클럭의 출력, 슬레이브인 경우 시리얼 클럭의 입력이 가능하다.
만약 MSP430을 마스터로 사용한다면 어떤 핀을 제어해야 하는지 감이 올 것이다.

다시 돌아와서 tinyos의 경우 USART1의 uart와 spi를 위해 HPL단의 컴포넌트에 레지스터 셋팅이 되어 있다.
(/opt/tinyos-1.x/tos/platform/msp430/HPLUSART1M.nc)
이를 사용하기 위해서는 top-level app단에서 인터페이스를 연결하여 call 하면 된다.
(/opt/tinyos-1.x/tos/platform/msp430/HPLUSARTControl.nc)

참고로 슬레이브 모듈에 따라 레지스터를 변경 적용해야 하는 경우도 있으니 MSP430Fx의 데이터시트를 꼭 참고해야 한다.

TIP.
TinyOS에서 StdControl interface를 이용하여 초기화할 때, SPI 모드도 초기화 하게 되면 동작이 되지 않는다. 그러므로 스케줄러에 의해 모트의 동작이 시작할 때 초기화하고 SPI로 동작하도록 해야 한다.

Sensor Node Reboot !!

2010-03-24T21:38:00.000-07:00

센서 노드의 reboot 기능을 다음과 같이 소프트웨어적으로 구현할 수 있다.

* MSP430
void reboot() {
WDTCTL = 0; //watchdog timer control
while(1);
}

* Atmega128
void reboot() {
wdt_enable(1); //watchdog timer
while(1);
}

What's TOSH?

2010-03-23T17:11:00.000-07:00

TinyOS에서는 여러 하드웨어 플랫폼에 직접 접근이 가능하도록 매크로를 지원한다. 각 핀에 대한 하드웨어 Assign 을 통해 함수가 자동으로 생성되며, 그 함수(매크로)를 이용하여 핀을 직접 제어할 수 있게 된다.

/opt/tinyos-1.x/tos/platform/msp430/msp430hardware.h 파일의 내용을 보면 아래와 같은 매크로가 정의되어 있다.

vmware image 하드 공간 확장

2010-03-09T18:23:00.000-08:00

윈도우에서 command를 이용하여 vmware 가 설치되어 있는 곳으로 이동한 후 다음과 같은 명령을 이용하여 용량을 늘려 사용할 수 있다.

vmware-vdiskmanager.exe -x 10Gb "E:\Virtual image\Ubuntu\Ubuntu.vmdk"

여러 개의 센서를 이용한 패킷 전송 방법

2010-02-16T18:47:00.000-08:00

센서 노드에 탑재된 여러 개의 센서를 제어하고 이를 통해 무선으로 패킷을 전송하는 방법을 살펴보자.

1. 센서의 갯수 만큼 타이머를 할당하여 타이머 이벤트에 따라 제어 및 전송하는 방식
- 센서로부터 센싱하는 시간이 대체적으로 길거나 신뢰성 있는 패킷 전송을 필요로 할 때 사용
- 전송시간이 길며 배터리 소모면에서 불리하다.
- 예시
event void Temperature.readDone(error_t result, uint16_t data){
//inject data to payload//
}
event void Humidity.readDone(error_t result, uint16_t data){
//inject data to payload//
}
event error_t AnalTemperature.dataReady(uint16_t data, uint8_t status){
//inject data to payload//
}
event error_t Light.dataReady(uint16_t data, uint8_t status){
//inject data to payload//
}
event error_t Microphone.dataReady(uint16_t data, uint8_t status){

//inject data to payload//
}
event error_t Gyro.dataReady(uint16_t data, uint8_t status){
//inject data to payload//
call Send.sendPacket(transmitPacketPtr);
}
event void Timer.fired(){
if(count % 6 == 1) call Temperature.read();
else if(count % 6 == 2) call Humidity.read();
else if(count % 6 == 3) call AnalTemperature.getData();
else if(count % 6 == 4) call Light.getData();
else if(count % 6 == 5) call Microphone.getData();
else call Gyro.getData();
count++;
}

2. 순차적으로 센서를 제어하는 방식으로 마지막으로 센싱된 후 패킷을 전송하는 방식
- 센싱이 빠르며 패킷 전송 또한 빠르다.
- 적절한 타이머를 사용하지 않으며 패킷 손실 및 전송 실패가 발생할 수도 있다.
- 예시
event void Temperature.readDone(error_t result, uint16_t data){

//inject data to payload//
call Humidity.getData();
}
event void Humidity.readDone(error_t result, uint16_t data){
//inject data to payload//
call AnalTemperature.getData();
}
event error_t AnalTemperature.dataReady(uint16_t data, uint8_t status){
//inject data to payload//
call Light.getData();
}
event error_t Light.dataReady(uint16_t data, uint8_t status){
//inject data to payload//
call Microphone.getData();
}
event error_t Microphone.dataReady(uint16_t data, uint8_t status){
//inject data to payload//
call Gyro.getData();
}
event error_t Gyro.dataReady(uint16_t data, uint8_t status){
//inject data to payload//
call Send.sendPacket(transmitPacketPtr);
}

tosboot

2010-02-16T18:45:00.001-08:00

/opt/tinyos-1.x/tos/lib/Deluge/TOSBoot

네트워크에서의 지연과 손실

2010-01-18T20:26:00.001-08:00

queuing delay
processing delay
transmission delay
propagation delay
end-to-end delay
packet loss

Nodes do not appear when using "lowpower"

2010-01-18T20:17:00.000-08:00

1. If you are compiling an application such as Delta using the "lowpower" option like this

make tmote lowpower

2. Then there is a known bug that causes synchronization to fail.

3. To prevent this bug, download this new version of NetSyncM.nc and copy it to the /tos/lib/netsync directory, replacing the existing file.
----------------------------------------------------------------------------------
void setSyncMaster() {
uint32_t now;
// if a find is in progress, disable the find
call SPNeighbor.findDone();
atomic {
m_smsg->hopcount = 0;
m_nexton = m_nextoff = 0;
broadcast.addr = TOS_BCAST_ADDR;
m_smsg->global_time = m_smsg->local_time = call LocalTime.get();
now = m_smsg->global_time & 0xFFFF0000;
broadcast.timeon = now + (TIME_ON 1 PERIOD);
broadcast.timeoff = now + (TIME_OFF 1 PERIOD);
m_smsg->on = TIME_ON;
m_smsg->off = TIME_OFF;
m_timeout = 0;
}
// insert into the neighbor table
call SPNeighbor.insert(&broadcast);
}
----------------------------------------------------------------------------------
4. Recompile and reinstall your application using make tmote lowpower for the changes to take effect.

Is this a bug in Moteiv Boomerang MultiHop?

2010-01-10T21:28:00.000-08:00

In selectParent() function of MultihopLQIM.nc, is the following line a bug?

if (parents[i].cost + parents[i].estimate < newparent) {

---------------------------------------------------------------------------

Should "newparent" be "parentestimate" ??

void selectParent() {
int i;
int newparent = m_parent;
uint16_t parentestimate = parents[m_parent].cost +
parents[m_parent].estimate;

// if our parent is invalid, pick the best parent
if (parents[m_parent].addr == MHOP_INVALID_PARENT) {
    for (i = 0; i < MHOP_PARENT_SIZE; i++) {
    if (parents[i].cost + parents[i].estimate < newparent) {
      newparent = i;
      parentestimate = parents[i].cost + parents[i].estimate;
    }
}
}
// if we have a parent, don't switch unless they're worthwhile

...

tinyos-help

interface Intercept...

2010-01-05T22:27:00.000-08:00

MultihopRoute 라이브러리에서는 intercept라는 인터페이스를 제공하는데 이 인터페이스는 멀티홉 라우팅 레이어에서 자신에게 전달된 패킷을 상위 레이어에서 참조할 수 있도록 해주는 것으로 데이터를 취합하고자 할 때 사용할 수 있다.

예를 들어 A->B->C->D 와 같이 멀티홉 라우팅을 할 경우
A: sned();
B: intercept();
C: intercept();
D: receive();
와 같이 동작하게 된다.

이 인터페이스는 /opt/tinyos-1.x/tos/interface/Intercept.nc 에 위치하며, 자세한 내용은 해당 파일을 참조하면 된다.
이 인터페이스는 MultihopRoute 라이브러리에서 구현하기 때문에 이 라이브러리로 wiring을 하여 사용하면 된다.

즉,
-----------------------------------------------------------------
configuration Test{
}
implementation {
component LQIMultiHopRouter as multihopM;

TestM.Intercept -> multihopM.Intercept[AM_SURGEMSG];
}

module TestM {
use interface Intercept;
}
implementation {
event result_t Intercept.intercept(...) {
if( LOCAL_ADDRESS == BASE_ADDRESS ) {
    if( data > threshhold ) {
      Leds.redOn();
    }
}
return SUCCESS;
}
}
-----------------------------------------------------------------
와 같은 식으로 구현하면 된다.

intercept 인터페이스에서는 intercept라는 이벤트를 발생시키는데, 이것은 자신에게 전달된 패킷이 도착했다는 것을 알려주는 것이며 이 때, 인수로 넘어온 패킷을 참조하여 데이터를 취합 하는 작업을 수행할 수 있다. intercept 이벤트 핸들러는 성공 여부를 리턴해주어야 하는데
하부에서 이 값에 따라 데이터를 포워딩할지의 여부를 결정한다. 즉 데이터를 취합하는 경우 수신된 데이터를 그대로 포워딩 하는 것이 아니라 자신에 데이터나 다른 노드에서 수신된 데이터들과 함께 취합한 다음 새로운 패킷으로 전송해야하기 때문에 단순한 포워딩이 아닌 Send()함수를 이용해서 전송을 해주어야 한다. 이를 위해 intercept 이벤트 핸들러에서 리턴 값으로 SUCCESS를 할 경우 단순히 포워딩을 하지만 FAIL을 리턴할 경우 포워딩을 안하기 때문에 상위레이어에서 취합한 데이터를 Send함수를 이용해서 전송할 수 있다. 상위에서 데이터 취합을 하면서 SUCCESS값을 넘겨주면 단순 포워딩도 하고 데이터 취합도 하는 것이기 때문에 중복된 데이터가 전송되는 경우가 발생하므로 주의해야 한다.

PDF 파일에 삽입된 워터마크 삭제

2009-12-15T00:52:00.000-08:00

PDF 파일에 이미 삽입되어 배포된 워터마크를 매우 간단한 방법으로 삭제가 가능하다.
아크로뱃 프로 7을 기준으로 다음과 같은 방법으로 날려보자.

1. 툴바에서 마우스 오른쪽 버튼을 눌러 나타나는 내용 중 [고급 편집] 도구를 활성화 한다.
2. [고급 편집]의 [Touch Up 도구]에서 [Touch Up 개체도구]를 선택한다.
3. 손바닥이 화살표 모양으로 바뀐것을 볼 수 있다.
4. 해당 워터마크를 선택하면 파란 상자로 지울 대상을 지정해 준다.
5. Delete 키를 이용하여 날리면 끝.

Tinyos-1.x SurgeTelos Bug

2009-12-01T17:55:00.000-08:00

tinyos-1.x/apps/SurgeTelos는 tos/lib/MultiHopLQI 라우팅 프로토콜을 사용한다.
tinyos-1.x/tos/lib/MultiHopLQI 에는 치명적인 버그가 하나 존재한다.
tinyos-1.x/tos/lib/MultiHopLQI/MultiHopLQI.nc 파일을 살펴보면 데이터 전송 시 initializeFields에서는 다음과 같이 처리한다.

251 command result_t RouteSelect.initializeFields(TOS_MsgPtr Msg, uint8_t id) {
252 TOS_MHopMsg *pMHMsg = (TOS_MHopMsg *)&Msg->data[0];
253
254 pMHMsg->sourceaddr = pMHMsg->originaddr = TOS_LOCAL_ADDRESS;
255 pMHMsg->originseqno = gCurrentSeqNo;
256 pMHMsg->hopcount = gbCurrentHopCount;
257
258 return SUCCESS;
259 }

여기서 255라인의 gCurrentSeqNo++ 해야 제대로 동작하게 된다.
만약 이 부분의 처리를 해 주지 않고 데이터를 30초당 1개 보다 빠르게 전송하면 데이터 패킷들이 selectRoute안에서 잘못 처리되는(duplicate suppression) 현상이 발생하게 된다.

tinyos-2.x/tos/lib/net/lqi/LqiRoutingEngineP.nc를 보게되면 이곳의 initializeField 함수는 위와 같이 제대로 고쳐져 있음을 확인할 수 있다.

이처럼 tinyos 코드에도 버그가 있음을 유념해야 한다.

TOSBase & Network Communication Lib

2009-11-11T19:00:00.000-08:00

TOSBase 와 Network Communication Lib. 에 대해 알아보자.
TOSBase 어플리케이션은 Bridge 역할을 한다.

즉, 송신 노드로부터 RF를 통해 전달되는 패킷을 수신하게 되면 TOSBase는 Group ID를 확인하고 자신의 Group ID 와 같으면 패킷을 받아서 시리얼(PC)로 전송하는 기능을 하며, 반대로 시리얼(PC)로부터 데이터를 전달 받으면 RF를 통해 네트워크로 전송하는 기능을 한다.
TOSBase 어플리케이션은 네트워크를 사용하는 다른 어플리케이션들과는 약간 다른 네트워크 라이브러리를 사용한다.
TOSBase 어플리케이션의 경우 RadioCRCPacket 라이브러리를 사용하는데 다음과 같다.

components Main, TOSBaseM, RadioCRCPacket as Comm, FramerM, UART, LedsC, CC2420ControlM;

RadioCRCPacket 라이브러리는 패킷을 받으면 CRC 체크후 에러가 없으면 상위 컴퍼넌트로 전달한다. RadioCRCPacket을 통해 올라온 패킷은 에러체크만 하고, 그룹 ID나 노드 ID는 필터링 되지 않는다.
TOSBase 어플리케이션이 RadioCRCPacket 라이브러리를 쓰는 이유는 네트워크로 수신되는 모든 패킷을 받기 위함이다.
그에 반해 OscilloscopeRF와 같은 일반적인 어플리케이션은 GenericComm 라이브러리를 사용한다.
GenericComm 라이브러리는 RadioCRCPacket을 통해 올라온 패킷들 중에서 그룹 ID와 노드 ID가 자신의 ID와 일치하는 브로드캐스팅된 패킷만 필터링 해서 상위 컴퍼넌트로 올려주는 역할을 한다.
즉, GenericComm 네트워크 스택을 사용하면 자신의 ID 또는 브로드캐스팅 주소로 전송되는 패킷만 수신하게 되는 것이다.
GenericComm과 RadioCRCPacket이 각각의 동작방식은 다르지만 제공하는 command와 event는 같으며, 일반적으로 컴포넌트명도 비슷하게 사용한다.
TOSBase 어플리케이션의 TOSBaseM.nc 파일과 OscilloscopeRF 어플리케이션의 oscilloscopeM.nc파일만 비교해보면 네트워크와 관련해서 같은 라이브러리를 사용하는 것처럼 보일 수가 있다.
그렇기 때문에 TOSBase.nc파일과 Oscilloscope.nc파일을 비교해 보면서 두 어플리케이션에서 각각 어떤 네트워크라이브러리를 사용하는지 알수가 있고 차이점을 파악할 수 있다.
그리고 RF를 통해 네트워크로 전송되는 패킷마다 패킷 ID를 가지며, 이 ID를 가지고 적절한 핸들러를 찾아 이벤트를 발생시켜주는데, 이 이벤트 핸들러는 상위 컴포넌트에서 구현해야 한다.
참고로 OscopeMsg.h 파일을 보면 다음과 같이 선언되어 있는 것을 볼 수 있다.

enum {
AM_OSCOPEMSG = 10,
AM_OSCOPERESETMSG = 32,
};

이처럼 네트워크를 이용하는 다른 어플리케이션들은 이와 비슷한 형태로 패킷별로 고유의 ID를 정해서 사용한다.
네트워크로 패킷이 수신되었을 때 그룹 ID와 노드 ID가 자신의 ID와 동일하더라도 패킷 ID에 대한 핸들러를 구현해놓지 않았으면 해당 패킷은 무시된다.
configuration 부분을 보시면 하위 컴포넌트들과 연결할 때 이 ID를 다음과 같이 지정해서 사용하는 것을 볼 수 있다.

OscilloscopeM.ResetCounterMsg -> Comm.ReceiveMsg[AM_OSCOPERESETMSG];
OscilloscopeM.DataMsg -> Comm.SendMsg[AM_OSCOPEMSG];

위의 경우 패킷을 전송할 때는 AM_OSCOPEMSG 를 패킷에 삽입하여 전송하고, 수신되는 패킷은 AM_OSCOPERESETMSG 를 ID로 가지는 패킷만 처리하겠다는 것을 의미한다.
단순히 Oscilloscope를 수정하여 send와 receive를 하게 되면 보내는 쪽에서는 AM_OSCOPEMSG를 패킷 ID로해서 보내지만, 수신측에서는 AM_OSCOPERESETMSG를 패킷 ID로 가지는 것만 필터링 해서 받기 때문에 전송측에서 보내는 패킷을 받을 수가 없게 된다.
그러므로 네트워크와 관련된 내용을 구현할 때는 configuration 파일을 잘 살펴보고 사용하는 라이브러리와 패킷 ID를 주의하여 사용해야 한다.

CC2420의 전원 제어

2009-11-08T17:55:00.000-08:00

tinyos 에서 cc2420의 제어와 관련된 컴포넌트는 CC2420RadioC 에서 담당한다. 여기서 cc2420 칩 자체의 전원을 컨트롤 할 수 있다.
CC2420Control.VREFOn() 과 CC2420Control.VREFOff() 를 사용하면 된다.
하지만 이를 사용하게 되면 전원이 On/Off 되는 과정에서 칩 자체의 초기화를 다시 해야 하는 불편함이 따른다.

그래서...
CC2420 칩 자체의 전원을 차단하지 않는 방법이 있다. 오실레이터라는 것을 이용하는 것이다.
CC2420Control.OscillatorOn()과 CC2420Control.OscillatorOff()를 사용하게 되면 칩 전원을 제어하는데 필요한 초기화등이 불필요 하므로 좀 더 효과적으로 사용할 수 있다.

CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance)

2009-11-08T17:01:00.000-08:00

센서 네트워크 기반에서 주로 사용되는 MAC 프로토콜 방식으로 물리계층과 네트워크 계층 사이에서 센서 노드 간 원활한 데이터 전송을 위해 직접 관여한다.
이는 데이터를 보내기 전에 보내고자 하는 채널 또는 링크에 다른 데이터가 전송되고 있는지 미리 확인하는 과정을 통해 해당 채널 또는 링크에 사용자가 없으면 이 때 자신의 데이터를 실어 보내는 방식을 취한다.

non-overlapping channel

2009-11-05T18:37:00.000-08:00

Bluetooth나 Ieee 802.11b/g등 수 많은 무선 기기들이 노출되어 있는 환경에서 노이즈 또는 충돌없이 신뢰성 있는 통신을 위해서는 동 주파수 대역내에서 중첩되는 채널의 회피 방안은 필수이다.
CC2420 RF Chip이 사용하는 2.4Ghz 대역은 ISM 영역으로 많은 통신 표준들이 이 주파수 대역을 사용하고 있다.
이 대역을 사용하는 무선 통신들은 노이즈나 충돌이 발생하게 된다.
(IEEE 국제 표준은 비영리 목적으로 사용되기 때문에...)
특히 이 주파수 영역에 영향을 미치는 것은 역시 802.11 AP들이다.
만약 해당 사용자 중 하나가 스트리밍 서비스를 무선 인터넷을 통해 받고 있으면 그 영역은 엄청난 손실이 발생하게 된다.
하지만 802.11 역시 해당 대역을 나누어 채널별로 사용하고 있다.
802.11은 미국기준으로 2.4Ghz에서 11개의 채널을 사용하게되는데, 이 채널은 서로간의 대역을 조금씩 침범하고 있으므로, 동시에 한 공간에서 11개의 채널을 충돌없이 사용할 수는 없다. 동시에 서로의 영향없이 사용할 수 있는 채널을 non-overlap 채널이라고 하는데, 이것은 11개의 채널들 중 1번, 6번, 11번 채널이다.
이 3가지 채널은 한 공간에서 동시에 사용해도 이론상으로 서로의 대역을 침범하지 않는다.
이 3가지 802.11의 non-overlap 채널들과 802.15.4(cc2420)의 채널들을 비교하면, cc2420이 제공하는 11번부터 26번 채널 중, 15번, 20번, 25번, 26번 채널은 802.11과 겹치지 않아 노이즈가 적으므로, 비교적 좋은 통신 성능을 보이게 된다.
만약 주변에 AP가 있을 경우, 15, 20, 25, 26번 채널을 선택하는 것이 좋고, AP가 없다면 802.15.4의 채널은 모두 서로 간에 non-overlap이기 때문에 어떠한 채널을 선택해도 큰 상관은 없다.

LDT(Location Determination Technology)

2009-11-02T18:23:00.000-08:00

GPS 또는 이에 준하는 무선 네트워크의 기지국 위치를 활용하여 서비스 요청 단말기의 정확한 위치를 파악하는 기술.

[ 거리정보 기반 위치측정 ]

1. ToA (Time of Arrival)
전송노드가 신호를 발생시켜 신호가 목적노드에 도달한 시간을 거리로 변환시키는 기술.
ToF(Time of Fight)라고 불리기도 함.
소리 or 초음파와 같은 신호를 전송하여 목적지에 도달하기까지의 시간에 신호의 속도를 곱한 값이 거리가 됨.
두 노드간 신호의 전송시간을 정확하게 하기 위해 양 단말간 클럭의 동기화가 정확히 이뤄져야함.
대표적인 예로 GPS가 있음

2. TDoA(Time Difference of Arrival)
속도가 다른 두 신호를 동시에 전송하여 목적지에 도착하는 시간의 차이를 거리로 환산하는 기술.
일반적으로 초음파 신호와 라디오 신호를 동시에 전송하며, 라디오 신호는 빛의 속도로 진행되고 초음파 신호는 음속으로 진행되는 속도의 차이를 이용함.
절대적인 시간 정보 없이 시간차를 이용하므로 동기화가 필요하진 않지만 실제로 동시에 두 신호를 보내기 어려우므로 오차 보정 방식을 취함.

3. AoA(Angle of Arrival)
센서에서 타깃이 보내는 신호의 방향각을 이용하여 각을 측정하고 각 센서와 타깃 사이의 방향각 교차점을 계산하여 타깃의 위치를 측정하는 기술.
최소 2개 이상의 방향각들이 필요하며 이들을 교차시킴으로써 위치 파악이 가능함.
타깃이 센서와 멀리 있다는 가정에 근거를 두어, 가까울 경우 주변환경에 의해 산란이 되어 부적절.

* 위 기술 모두 LOS에 의존하여야 하지만 Non-LOS지역의 반사와 굴절로 인해 측정에 오류가 발생함. 이를 해결하기 위해 많은 논문들이 해결책을 제시하고 있음

4. RSSI : 수신신호의 세기에 기반을 둔 위치측정
RSSI(Received Signal Strength Indication)는 신호를 수신한 노드가 신호의 강도를 이용하여 신호가 감쇄된 정도를 거리로 환산하는 방법.
미리 정의된 다양한 지점에서 신호 세기들을 RSSI 표본 수집을 통해 측정 후 타깃의 송신 신호를 각 센서들이 수신할 때 발생하는 신호의 감쇠정도를 측정한 뒤 이를 확률적 방법을 통해 미리 수집되었던 RSSI 표본과 매칭하여 위치 측정.
장애물이 존재하거나 복잡한 실내 환경일 경우 거리 측정 오차가 매우 큼.

[거리정보에 기반을 두지 않은 위치인식 기술]

1. 중점기법
앵커의 비컨 신호를 사용하며 타겟의 위치는 다수의 앵커로부터 한 홉으로 인식이 가능한 공통된 지역의 중심으로 나타냄.

2. APIT(Approximate Point In Triangle)
한 홉으로 연결이 가능한 앵커들로 삼각형을 형성하고, 타겟 노드가 그 삼각형 내부에 있는지의 여부를 인식한 후, 타겟노드를 포함하는 삼각형 영역의 중첩된 영역의 중심점을 타겟의 위치로 결정하는 알고리즘.
앵커는 수많은 삼각형을 형성하기 위해 전송범위가 긴 방향성 안테나를 장착해야 함.
타겟노드를 포함한 일반 미지노드들은 앵커로부터 수신된 신호의 세기를 측정할 수 있어야 함.

zigbee RF 주파수 특성

2009-10-04T18:38:00.000-07:00

zigbee RF 특성
zigbee에서 대표적으로 사용하는 주파수인 2.4GHz 영역 주파수의 일반적인 전달특성은 직접파와 반사파에 의존하며 회절에 의한 전파 전송이 잘 안 되는 특성이 있다.
다음은 2.4GHz 대역 zigbee 모듈의 RF 규격이다.

변조방식 : DSSS/O-QPSK
사용주파수 : 2400 ~ 2483.5MHz
최대송신속도 : 250Kbps
최대출력파워 : 10dBm
최저수신감도 : -94dBm
채널 수 : 16
채널간격 : 5MHz

통상적인 경우의 zigbee 출력은 0dBm이며, 전파법규상 최대 10dBm까지 증폭이 가능하다.

자유대역에서 전파
자유공간에서의 zigbee의 무선 파의 전파(propagation)특성을 확인하기 위하여 거리 별 수신레벨과 PER(Packet Error Rate)을 측정해 보면 송신 지점에서 200m 떨어진 지점까지는 PER 0%이며, 이 때의 평균 수신레벨은 -92dBm이며 200m 이후 지점부터의 수신레벨의 감소폭은 작아지나 패킷 에러율이 급상승한다.

가정 내의 전파환경
가정 내의 무선 전송 환경은 자유공간과 달리 무선 전송을 방해하는 여러 가지 장애물들로 가득하다. 고정된 장애물도 있고 이동하는 장애물들도 있는데, 고정된 장애물인 내부 벽의 투과 손실은 10~30dB이며 벽의 종류, 두께, 콘크리트 내부 철재의 구조, 전파의 입사각 등에 의해 투과 손실은 각각 다르게 나타난다. 같은 구조의 집에서도 무선 전송 환경은 각각 다르므로 예측에 의한 무선망 설계는 실수로 이어질 수 있으며, 이를 방지하기 위해서는 zigbee 전용 패킷 툴과 같은 전파 환경 측정 장치를 사용하는 것이 바람직하다.
유동적인 장애물의 경우 사람의 이동, 문의 개폐, 가구 또는 가전제품의 재배치등이 있다. 문의 개폐 상황에 따른 전파환경 변화에 대한 대책으로는 망 설계 시 모든 문을 닫고 설계하여 통신 안정성을 확보하는 방법이 있으나, 사람의 이동이나 가구 등의 재배치에 따른 환경변화에는 별 다른 대책이 없으므로 변화에 대응이 가능한 정도의 여분을 주어 네트워크의 안정성을 확보해야 한다.
가정 내에서의 전파환경은 다른 무엇보다도 내부 구조에 가장 큰 영향을 받는 것으로 확인되며, 집의 크기에 의한 영향은 비교적 적다. 이러한 원인으로는 같은 구조의 50평형대와 30평형대의 아파트의 중심에서 가장자리까지의 거리차이는 2~3m 차이 밖에 나지 않기 때문이다. 벽을 몇 개를 통과하는지, 벽의 두께 및 재질이 무엇인지, 반사파가 어떤 경로로 도달하는지 등이 가정 내 무선전송의 거리를 형성하는 주요 변수이다. 신축현장에서는 이러한 벽의 두께 및 벽 내부의 철근 구조 등을 비교적 알기 쉽고, 아파트의 경우 동일 크기에 같은 구조이므로 비교적 전송거리의 결정이 쉬우나, 단독주택과 같은 경우에는 설치자가 직접 측정에 의해 전송거리를 결정해야만 안정적인 통신을 보장 받을 수 있다.

주파수 간섭
zigbee 기기들은 가정 내에서는 WLAN, Bluetooth와 같은 동일한 주파수 대역을 사용하는 기기들과 공존하면서 동작이 되어야 한다. 그러므로 이들 간의 간격 또한 zigbee 기술을 이용한 홈네트워크 방법에서는 중요한 요소로 작용한다. zigbee가 채택한 PHY/MAC 규격인 IEEE 802.15.4는 주파수 대역으로 2.4GHz를 권고하고 있으며, 현재 대부분의 zigbee 기기들은 Bluetooth, WLAN등이 사용하는 주파수 대역인 2.4GHz 대역의 칩을 사용하므로 이들 무선기술간의 간섭이 문제로 부각되고 있다. 이 간섭 문제를 적극적으로 해결하기 위해서 근본적으로 간섭을 피하려는 노력을 하고 있다.

- zigbee803 -

Kaist의 김진수 교수님께서 작성하신 공감 100배

2009-09-29T19:42:00.000-07:00

Kaist의 김진수 교수님께서 제자들에게 전하고자 하는 내용이라고 한다.
정말 가슴 깊이 생각하고 공감하게 만드는 글의 내용이다.
다음은 그 내용의 전문이다.

--------------------------------------------------------------------

Weekly reports만 올라오니 너무 썰렁해지는 것 같아서..

대학원 생활을 하는 여러분에게 평소에 하고 싶었던 말 몇 가지를 적어봅니다.

Computer Science/Engineering 연구

물리학, 화학, 수학과 같은 자연과학은 신이 만들어 놓은 자연의 이치를 깨닫고자 하는 학문입니다. 진짜 신이 수소, 산소, 질소 등등의 각종 원소를 이용해서 물질을 만들게 하셨는지는 아무도 모릅니다. 단지 과학자들이 하는 일은 현상을 잘 설명할 수 있는 그럴듯한 가설을 만들고 그것이 현상을 제대로 설명하는지를 확인하는 일을 반복할 뿐입니다. 따라서 자연과학에는 "왜?" 그렇게 되었는지에 대해서 물을 필요도 없고, 단지 발견과 경탄만이 존재할 뿐입니다.
그러나 우리가 업으로 삼고 있는 computer science 혹은 computer engineering 분야는 신이 만든 것이 아니라 사람이 만들어 놓은 computer system을 학문의 대상으로 합니다. 따라서, 자연과학과는 본질적으로 학문의 성격이 틀릴 수 밖에 없습니다. Computer science에서의 연구는 어떻게 돌아가는지 "발견"을 하는 연구가 아니라, "왜" 그렇게 만들었는지를 알아내고, "어떻게 하면" 더 잘 만들 수 있을까 위주로 연구가 이루어지게 됩니다. 몇몇 사람들에게 이미 우스개소리로 말한 바 있지만, 결국 연구의 시작은 남이 한 일에 대해서 트집을 잡는 것부터 시작되는 것입니다. 논문을 하나 읽으면, 그 논문의 아이디어는 무엇인지, 어떻게 자신의 아이디어가 좋다고 설득을 했는지, 그리고 문제점이나 제한점은 무엇인지 분석하는 습관을 항상 들이기 바랍니다. 이러한 것을 생각해 보지 않는다면, 아무리 많은 논문을 읽어도 연구에 별 도움이 되지 않습니다. (영어에는 도움이 됨)

결국은 창의력 싸움

웅진 씽크빅 CF에서 "이젠 창의력이 경쟁력"이라는 말이 나오는데 예전에는 저도 창의력이 그렇게 중요한지 아무 생각이 없었습니다만, 요즘 들어서는 결국은 창의력이 문제라는 생각을 하게 됩니다. 일단 다른 사람이 한 일에 대해서 트집을 잡았다면, 자신이 했다면 어찌 했을지를 생각해 보아야 하는데 이 부분에서 창의력 있는 사람과 창의력 없는 사람이 드러납니다. 만일 몇몇 논문을 읽고, 중요한 것은 다른 사람들이 이미 모두 파먹어서 나는 별로 할게 없다는 생각이 드는 사람은 일단 자신의 창의력을 의심해 보기 바랍니다. 당신이 그렇게 생각하고 시간을 보내는 사이에도, 꾸준하게 새로운 논문들이 쓰여지고 있습니다.
처음부터 창의력이 있고, 창의력이 없는 사람이 있는 것은 아니라고 봅니다. 창의력은 계속 이것저것을 생각해 보는 훈련에 의해 충분히 그 역량이 늘어날 수 있습니다. 한가지 권장하고 싶은 방법은, 어떤 논문의 introduction만을 읽고, 혼자 생각해 보는 방법입니다. 논문의 introduction을 읽으면, 그 논문이 대상으로 하고 있는 background와 문제점, motivation 등이 나옵니다. 그럼, 그 부분에서 논문 읽는 것을 중지하고, 해당 문제점을 해결하기 위해 자신이라면 어떤 식으로 approach 하겠는지를 생각해 봅니다. 또한, 그것을 어떤 방법으로 실험하고 다른 사람에게 설득했겠는지를 생각해 봅니다. 마치, 연구 topic이 주어졌을 때 본인이 그것에 대한 논문을 쓴다고 생각하고 자유롭게 풀어나가라는 뜻입니다. 그런 다음, 논문의 나머지 부분을 읽어보고 자신의 생각과 비교해 봅니다. 비교를 하면 보통 세가지 경우 중의 하나입니다. 첫째, 자신의 생각이 너무 단순해서 논문의 related work에 나와있는 경우 - 그 정도로는 안된다는 뜻이죠. 둘째, 자신의 생각과 논문의 아이디어가 거의 비슷할 때 - 아쉽지만 나도 할 수 있다는 자신감을 갖게 됩니다. 셋째, 논문의 아이디어나 related work에 나와 있는 내용과 다를 때 - 새로운 논문이 될지도 모릅니다. 그러나 다른 사람이 이미 했을지도 모르니 관련 연구를 다시 자세히 조사해 보는 것이 필요합니다.
대개의 경우 관련 연구를 조사해 보면, 누군가 이미 한 경우가 대부분이지만, 혹시 아무도 자기가 생각한 것을 시도해 보지 않았다면... 결과가 좋게만 나온다면 새로운 논문이 될 가능성이 많습니다. 그러나 십중팔구, 아이디어는 좋은 것 같아서 시도해 보았는데 결과는 생각보다 좋지 않은 경우가 또 대부분입니다. ㅠ.ㅠ 이 경우, 어떤 사람들은 결과가 좋지 않으니 더 해 볼 생각도 안하고 거기서 그냥 하던 일을 접곤 합니다. 그러나 그렇게 되면 투자한 시간과 노력이 전부 날라가게 됩니다. 그 보다는, 무엇때문에 자신이 생각하던 결과와 차이가 나는지를 분석하고, 원래의 아이디어를 수정하고 optimize 해 나가는 것이 바람직합니다.
가끔 제가 여러분에게 이러저러한 일을 해 보면 어떻겠냐고 할 때에는, 저도 그 결과가 좋을지 나쁠지 정확히 알 수 없는 경우가 대부분입니다. 어렵게 일을 해서 결과를 뽑으면 결과가 안 좋게 나올 때도 있을 것입니다. 그렇다고 해서 거기서 주저앉지 말고, 그 결과를 어떻게 하면 활용하고, 향상시킬 수 있는지 고민하는 사람이 되었으면 좋겠습니다. 한 두 번 생각해서 좋은 생각이 떠오르지 않는다고 포기하면 안 됩니다. 그 정도로 해결이 될 것이라면 이미 누군가는 시도해 보았을 가능성이 많기 때문입니다. 자나 깨나 밥먹을 때나 샤워할 때나 문제를 생각하다 보면 좋은 생각이 떠오르는 때가 틀림없이 있을 것입니다. 정 안되어서 문제를 해결할 수가 없더라도, 자신이 시간과 노력을 들인 일에 대해서는 어떻게 하던지 논문으로 정리를 하기 바랍니다. 논문 내용이 아무리 해도 더 이상 안되더라..가 되더라도 말입니다.

Discussion의 중요성

창의적인 아이디어는 항상 처음에는 허황되게 보이기 마련입니다. 허황되어 보이는 아이디어를 다른 사람들이 그럴듯하다고 생각되게 만드는 과정이 연구입니다. 자신의 아이디어를 발전시키는 중요한 방법 중의 하나는 다른 사람과 discussion을 하는 것입니다. Discussion을 하는 것은 여러가지 면에서 연구에 중요한 도구입니다. 다른 사람에게 자신의 생각을 논리적으로 설명하려다 보면, 자신의 아이디어도 정리되고, 자신이 빼먹고 있었던 사실도 알게 됩니다. 그리고, 일반적인 경우 다른 사람의 아이디어를 들으면 대부분의 사람들은 부정적인 입장에서 공격을 하게 됩니다. 그러면 그러한 사람들을 설득시키는 과정에서 자신의 아이디어의 장단점이 무엇인지 파악되고, 새로운 아이디어가 나오게 됩니다.
물론 제가 여러분의 discussion 상대가 되겠지만, 여러분끼리의 discussion도 많으면 많을수록 좋겠습니다. 간혹 보면, 이것은 나의 일이고, 저것은 쟤가 맡은 일이라서 서로 간섭하지 않으려고 하는 경향이 있으나 그것은 결코(!) 바람직하지 않습니다. 남이 무슨 일을 하고 있는지 알아서 서로서로 도움을 주고 받을 수 있는 문화가 되었으면 좋겠습니다. 제가 weekly reports를 공개적으로 이 곳 게시판에 올리게 하는 이유도 자신이 하는 일 뿐만이 아니라 다른 사람이 무엇을 하고 있는지에 대해서도 관심을 가지게 하기 위함입니다.

실험에 대한 사전 고려

어떤 아이디어가 좋다는 것을 다른 사람에게 설득하기 위해서는 무엇이 좋아지는지 구체적인 증거를 들이밀어야 합니다. 구체적인 실험 결과가 없이 단지 말로만 이것이 저렇게 좋아진다고 하는 것은 software engineering 같은 데서는 통할지 몰라도, 우리 분야에는 통하지 않습니다. 따라서, 아이디어가 좋다고 해도, 그것을 증명할 방법을 찾지 못하면 그것은 무용지물입니다. (진짜 아이디어가 좋다면 특허는 낼 수 있습니다. 특허에는 아이디어가 좋다고 증명할 필요가 없으므로...)
결국, 적당한 실험이 뒷받침되지 않은 아이디어는 허공에 대고 메아리치는 격입니다. 이것은 바꿔 말하면, 아이디어를 발전시켜 나가는 초기부터 어떻게 실험을 해야 할지 미리미리 고려를 해야 한다는 뜻입니다. 만일, 어떤 주제에 대해서 연구를 시작할 때, 우리가 가지고 있는 infrastructure를 가지고 실험을 해 볼 수 있는 것인지를 함께 생각해 보기 바랍니다. 실제 implementation을 할 수 있겠는지, 아니면 필요한 simulator를 얻을 수 있는지, benchmark로는 무엇을 사용하면 되는지 등등에 대해서 사전 검토가 필요합니다.
이러한 점에서 저는 예전에 비해 연구 환경이 매우 나아졌다고 생각합니다. 예를 들어, 제가 학교 다닐 때에는 우리나라에서 OS나 architecture에 대해서 연구하기가 매우 힘들었습니다. OS에 관한 아이디어가 있어도 OS source code가 없으니 implement 해 볼 방법이 없었고, architecture에 관한 연구도 이와 사정이 비슷하였습니다. 그러나 이제는 Linux와 같이 source code가 가용한 OS를 이용할 수 있으니, 무언가를 해 볼 수 있는 여지가 많이 생겼습니다. 저는 Linux를 좋아하고 즐겨 사용하지만, open source니 뭐니 그런 것 보다도, 일단 연구의 중요한 도구라는 점에 의의를 두고 있습니다. 이제는 Linux 상에서 무언가를 했다고 해도 그 사실만으로는 태클을 받지 않는 정도의 수준까지 올라왔으니, 학교의 입장에서는 연구를 하는데에 굉장히 큰 도움이 되는 것은 사실입니다. Architecture에서도 요즘에는 SimpleScalar와 같은 좋은 시뮬레이터들이 많이 있어서 연구에 활용되고 있으니, 이제 실험을 못해서 논문을 쓰기 어렵다는 핑계를 대기도 힘들어 졌습니다.
어쨌거나 요약하면, 적절한 실험을 통하여 검증해 볼 수 있는 아이디어만을 일단 연구의 대상으로 하는 것이 좋겠다는 것입니다. 이렇게 하면 단지 장비나 실험 환경이 없어서 여러분의 좋은 아이디어가 사장될 지는 모릅니다. 그러나 검증할 수 없는 아이디어에 대해서 시간을 보내고 있기에는 여러분의 시간이 너무나 한정되어 있습니다. 졸업들 빨리 해야죠...

많은 사람의 관심이 되는 topic vs. 일부의 사람들만 관심있는 topic

연구 topic, 특히 박사학위 논문 topic에는 두가지가 있습니다. 하나는 아주 일부의 사람들만 관심이 있는 topic입니다. 이것은 community도 작고, 관련된 컨퍼런스나 워크샵도 수가 작습니다. 일부의 사람들만 관심이 있는 이유는 다른 사람들이 별로 중요하지 않다고 생각하거나, 현실성이 없거나, 너무 미래지향적이거나 하기 때문입니다. 다른 하나는 많은 사람들이 현재 active하게 연구하고 있는 topic입니다. 이런 분야는 많은 사람들이 달라 붙어있기 때문에 논문도 많이 발표되고 굉장히 속도가 빠르게 진행됩니다.
전자의 경우에는 사람들이 적기 때문에, 경쟁도 그리 심하지 않고, 시간적인 여유도 있고, 잘(!)만하면 비교적 쉽게 논문을 쓸 수 있을 가능성이 있습니다. 그러나 그렇게 논문을 쓴다고 해도 일부의 사람들만 인정을 할 뿐입니다. 반면, 후자의 분야는 내가 하고 있는 것을 남이 한 발 앞서 할 수도 있고, 경쟁도 매우 심하지만, 일단 그런 경쟁을 뚫고 논문을 발표하게 되면, 많은 사람들이 자신이 한 일에 대해서 관심도 갖고 국제적인 지명도도 얻게 됩니다.
두 가지 종류의 topic 중 어떤 것을 선택할 지는, 개개인의 성향입니다. 저보고 추천하라고 하면, 저는 힘들지만 후자를 선택하라고 하겠습니다. 많은 사람들이 연구하는 topic에서 일을 하는 것은 많은 시간과 노력과 때로는 좌절을 수반하지만, 그만큼 보람도 큰 법입니다. 제가 앞서 중요한 conference 들을 언급하였는데, 그러한 conference에 논문을 발표한다는 것은 여러분이 후자의 일을 하고 있다는 뜻입니다.

능동적/공격적인 연구

능동적 연구라고 함은 누가 시키지 않아도 스스로 연구를 해 나아갔으면 좋겠다는 뜻이고, 공격적인 연구라 함은 논문쓰는 것을 두려워 하지 말라는 뜻입니다.
능동적인 연구를 강조하는 이유가 교수가 논문지도 안하고 놀기 위함은 절대(!) 아닙니다. 석사건, 박사건, 졸업을 하는 것은 지도교수보다는 본인의 역량이라는 점을 명심하시기 바랍니다. 지도교수가 밥상을 차려줄 수는 있어도, 밥을 먹는 것은 본인입니다. 제가 석사 신입생들 면접할 때도 얘기를 했는데, 대학원은 제가 여러분을 귀찮게 하는 곳이 아니라, 여러분이 저를 귀찮게 하는 곳입니다. 언제라도 어떤 문제에 대해 저와 얘기하고 싶다면 제게 찾아오시기 바랍니다. 대부분 제가 잘 알지 못하는 내용이 될 가능성이 높지만서두...^^. 가끔 보면 지도교수가 옆에서 이거해 봐라, 저거해 봐라 하는 경우에는 왜 하는지도 모르고 별로 신도 나지 않은 채로 일을 하지만, 지도교수가 아무 신경도 쓰지 않으면 오히려 불안해서 스스로 연구를 하게 되는 경우가 많은 것 같습니다. 저도 여러분의 졸업과 관련하여서는 귀찮게 하지 않을 작정이니 졸업하고 싶으면 스스로 알아서 하세요.
공격적으로 연구를 하라는 것은 좋은 논문 하나에 집착하지 말라는 뜻입니다. 간혹 보면 대학원, 특히 박사과정에 들어오면 박사 논문 topic을 찾아 헤매서 돌아다니고, 그 외의 일은 신경도 쓰지 않는 것을 봅니다. 큰 거 한 방을 찾는 거죠. 하지만, 논문도 써 본 사람이 잘 쓰는 법입니다. 실제 박사논문 topic을 잡아서 집중적으로 일을 하기 전에, 작은 아이디어라도 논문으로 만들어 내어 보고, 영어 엉터리라고 reject도 당해 보고, accept 되어 다른 사람들 앞에서 영어로 발표도 해 보고 할 기회를 갖기를 바랍니다. 몇 번 해 보면, 대충 어떻게 돌아가는 건지 감도 잡히고, 실제 본 무대에서 뛸 때 도움이 됩니다. 야구 선수들도 처음에는 minor league에서 연습하다가 major league에서 뛰는 것과 마찬가지로, 작은 아이디어라도 실험 결과를 뽑고, 논문으로 만들어서 좀 떨어지는 컨퍼런스나 워크샵에라도 발표하려는 노력을 하기 바랍니다. 제가 생각하기에는 박사 1-2년차때 석사논문 내용이나, 수행한 project, course term project에서 한 일들을 가지고 major/minor conference에 한 두 개의 논문을 발표해 보고, 박사 3년차 이후에 본격적으로 자신의 topic에 대해서 연구하여 major conferences에 논문 2개 이상, 그리고 journal 논문 하나 이상 정도를 쓰고 졸업을 하면 좋겠습니다. 석사과정의 경우에도, 웬만한 conference에 실을 수 있을 정도가 되어야 석사 논문으로 적당합니다. 석사 논문을 쓰면 그것을 정리해서 conference나 정보과학회 논문지에 내어 보는 것을 권장합니다.
또 하나, 능동적/공격적인 연구와 관련하여 제가 강조하고 싶은 것은, 앞에서도 얘기했지만 절대 혼자서 모든 것을 다하려고 하지 말라는 것입니다. 좋은 아이디어가 있으면 혼자 끙끙거리지 말고, 다른 사람과 상의하고 일을 나누어서 하세요. 혼자서 논문 2개 쓰는 것보다, 둘이서 논문 4개 쓰는 것이 훨씬 쉽습니다. 그리고, 같이 일하는 사람이 후배일 경우에는 후배에게 일을 가르쳐주는 효과도 있게 되겠죠.
마지막으로, 대학원에 들어올 때는 순서대로 들어오지만, 졸업은 반드시 들어온 순서대로가 아니라는 점입니다. 때로는 선배를, 혹은 교수를 뛰어 넘어 자신의 능력을 발휘하는 여러분이 되기 바랍니다. 그리고, 석사과정에 있다 하더라도 반드시 4학기를 채워야 할 필요는 없습니다. 3학기만에 조기졸업을 할 수도 있고, 이제 석박사 통합과정이라는 것도 생겼으니 필요하면 이용하시기 바랍니다.

논문의 first author

논문을 쓸 때 주의할 점은 아이디어를 낸 사람이 반드시 first author가 되는 것은 아니라는 점입니다. First author는 기본적으로 해당 논문을 작성할 때 주도적으로 writing을 한 사람입니다. 즉, 아이디어를 A가 냈다고 하더라도, 논문을 B가 썼다면 B가 first author가 된다는 것입니다. 이것은 아이디어를 내는 것에 못지 않게 그 아이디어를 구체적으로 논문화하는 데에도 많은 시간과 노력이 들어가기 때문입니다. 그러니 아이디어내고, 실험 결과만 뽑았다고 해서 자동적으로 first author가 되는 것은 아니라는 점을 명심하시기 바랍니다. 논문의 first author가 되기 위해서는 그 논문을 실제로 본인이 작성해야 합니다.

연구는 타/이/밍

항상 computer systems에서도 resource management가 문제가 되는데, 여러분의 대학원 생활에도 자원 관리, 특히 여러분의 시간 관리가 중요합니다. 대학원, 특히 박사과정에서는 어리버리 하다 보면 시간이 금새 지나가는 수가 많습니다. 박사 1-2년차에는 랩일 하고, 코스웍 듣고 하다 보면 가고, 3년차는 뭔가 해 봐야지 하면서 보내고, 4년차가 되면 슬슬 초조해지기 시작하는데 박사논문 topic은 잘 안 잡히고, 5년차에 다행이 topic하나 잡아서 한 6개월 죽어라 일을 하고 간신히 졸업하면 다행... 인 것이 잘못하면 걷게 되는 여러분의 운명입니다.
일단 가장 문제가 되는 것은 빨리 졸업해야 되겠다는 motivation의 부재입니다. 그냥 사람들 좋고, 시간 여유 많고, 사회에 나가는 것도 두렵고, 그러다가 보면 대학원 생활에 익숙해 지고, 왜 대학원에 있는지도 모르고, 빨리 나가고 싶은 생각도 없고 그렇게 됩니다. 국내 대학원에 있는 사람과 유학간 사람들을 비교해 볼 때, 대부분 국내에서 박사학위를 하는 사람들이 상대적으로 performance가 떨어진다고들 합니다. 이것이 원래 부지런하고 자기 앞가림하는 사람들이 유학을 갔기 때문이라고 보는 사람도 있으나, 저는 기본적으로 국내에서 박사학위를 하는 대학원생들이 유학간 사람들에 비해 motivation과 긴장도가 떨어지고 열심히 하지도 않기 때문이라고 생각합니다. 제가 그래봤기 때문에 잘 압니다.
여러분이 할 일이 많다는 것은 저도 잘 아나, 대학원에 있는 동안 만이라도 일단은 연구에 우선 순위를 두었으면 하는 것이 제 바램입니다. 졸업하고도 할 수 있는 일은 대학원에 있는 동안은 잠시 미뤄두세요. 그게 싫다고요? 그러면 열심히 연구해서 빨리 졸업하고 그 다음에 하고 싶은 것 실컷 하면 되지 않습니까? 이렇게 얘기한다고 해서 매일 모니터 앞에만 앉아있으라는 말은 아닙니다. 사람이 연구만 하면서 살 수는 없으니까 가끔 기분전환도 하고 술도 마시고, 게임도 하고 그래야 되겠죠. 따라서 결국은 시간 관리를 잘 해야 하는 문제가 되는데, 제가 볼때는 생산성과 집중력이 중요합니다.
연구는 타이밍입니다. 특히 많은 사람들이 관심을 가지고 있는 topic에 대해서 일을 할 경우에는 더욱 그러합니다. 나에게 참신한 아이디어가 있더라도, 내가 어리버리하면서 시간을 보내고 있는 사이 다른 사람이 비슷한 아이디어를 발표해 버리면 내가 들인 시간은 물거품이 됩니다. 가끔 어떤 참신한 아이디어가 있으면, 저는 빨리 결과 뽑아서 논문으로 만들고 싶은데, 정작 그 일을 하는 학생은 여유를 가지고 일을 하는 바람에 제 속만 타는 경우가 있습니다. 저는 누가 먼저 발표할까봐 불안해 죽겠는데 말이죠. 따라서, 같은 일을 하더라도 1년 내내 일을 꾸준히 성실하게 하는 사람보다는, 6개월에 집중해서 끝내고 나머지 6개월을 탱자탱자 보내는 사람이 훨씬 더 낫습니다.

학자적 양심

나중에 졸업 등에 스트레스를 받게 되면 한순간 실험 결과를 조작하고 싶은 충동이나 다른 사람의 아이디어를 내 것인냥 슬쩍 빌려오는 등의 유혹을 받게 될 경우가 있는데, 이것은 무!조!건! 절!대! 안 됩니다. 왜냐고요? 바로 학자적 양심 때문입니다. 도덕적인 양심이 있듯이, 배운 사람에게는 학자적 양심이라는게 있습니다. 누가 강요하지 않아도 스스로 지켜야 할 선이 있는 거죠.
일전에 우연히 정보과학회 춘계 학술대회 논문집을 넘겨보다가, 우리 랩 학생이 말도 안 되는 논문을 낸 것을 보고 혼낸 적이 있습니다. 이미 웬만한 사람은 다 알만한 내용을, 심지어 예제 코드로도 많이 나오는 내용을 논문이랍시고 버젓이 쓴 것이 실렸기 때문입니다. 물론 정보과학회 학술대회 논문집을 살펴보면 말도 안되는 논문들이 많은 것은 사실이고, 그런 논문들이 심사 과정에서 걸러지지 않는 것도 문제이긴 합니다. 또한, 정보과학회 학술대회 논문의 경우에는 교수님들께서 일일이 신경을 쓰시지도 않고요. 그러나 그렇다고 해서 그런 논문을 실을 수는 없는 일입니다. 왜냐하면, 많은 사람들이 KAIST에서는 도대체 무슨 일을 하고 있는지 주의 깊게 살펴보고 있기 때문이죠. 여러분이 허접한 논문을 발표하면 여러분 논문 발표 실적에 한 줄 더 쓸 수는 있겠지만, KAIST나 여러분의 지도교수, 혹은 여러분 자신의 얼굴에 먹칠을 하게 되는 것입니다. 많이 배울수록, 스스로 지켜야 할 선의 수준도 높아지기 마련입니다.

KAIST의 특수성

마지막으로 여러분에게 부탁하고 싶은 점은, 특히 KAIST 학생으로서의 책임감을 가져달라는 점입니다. KAIST는 다른 학교와는 달리 많은 부분을 정부의 지원, 그러니까 국민의 세금에 의존하고 있는 학교입니다. 여러분 한명을 교육시키기 위하여 여러분의 부모님들을 포함한 얼마나 많은 사람들이 일하고 세금을 내는지 생각해 보기 바랍니다. 그렇게 여러분을 믿고 지원해 준 국민들에게 보답하기 위해서라도, 좋은 연구하고 빨리 졸업해서 사회에 보탬이 되는 일을 하는 것이 바람직합니다. 만일 여러분이 하라는 공부는 안 하고 게임하면서 하루하루를 지세운다면, 제가 보기에는 공적자금 빼돌리는 악덕 기업주와 다를 바가 없습니다.
많은 KAIST 학생들이 자신은 머리가 좋기 때문에, 아니면 여기까지 온 것도 경쟁을 뚫고 들어온 것이기 때문에 이만한 혜택을 받을 자격이 있다고 생각하는 경향이 있습니다. 그러나 사장이 되기까지 힘들었으니 이제 돈을 빼돌려도 된다는 것이 합리화되지 않는 것처럼, 여러분이 KAIST 학생이 되었다는 것이 여러분이 받고 있는 혜택을 당연하게 만드는 것은 아닙니다. 때로 여러분이 지치거나 힘들 때, 얼마나 많은 학생들이 여러분과 함께 KAIST에 들어오고 싶어 했고, 지금도 KAIST에서 공부하기를 꿈꾸면서 얼마나 많은 후배들이 공부하고 있는지 생각해 보기 바랍니다.

이것이 석사논문 주제가 되나요? (version 0.2 추가)

많은 학생들이 찾아와서는 묻습니다. "제게 이러저러한 아이디어가 있는데 이것이 석사논문 주제로 적당할까요?" 라고요. 태어날 때 천한 사람, 귀한 사람이 따로 있는 것이 아니듯이, 저는 처음부터 석사논문으로 적당한 topic이 따로 있는 것은 아니라고 생각합니다. 어떤 topic이 석사논문으로 적당한 지의 여부는 전적으로 그것을 주장하는 여러분에게 달려 있습니다. 즉, 여러분이 그것이 왜 중요하고, 어떤 점이 나아지며, 다른 사람이 한 일과는 어떻게 다른지를 논문 committee에 있는 교수님들이나 다른 사람들에게 효과적으로 설득할 수 있는지의 여부가 더욱 중요하다는 점입니다. 학위논문 심사를 보통 디펜스(defense) 한다고 하는데, 이것은 많은 사람들의 공격으로부터 자신이 한 일이 중요하다는 것을 설득시키고 지켜낼 수 있어야 하기 때문입니다.
자기의 논문을 디펜스하기 위하여 무엇보다도 중요한 것은 앞에서도 언급했듯이 다양하고 많은 사람들과의 discussion 입니다. 혼자서 생각하다보면 한쪽으로만 생각이 흐르는 경향이 있어서 중요한 것을 못보고 지나칠 가능성이 많습니다. 그러나 백그라운드가 다른 여러 사람에게 자기가 한 일을 설명하고 이해시키려고 하다 보면, 그 사람들이 이해하지 못하는 점을 설명해 주는 과정에서 놓치고 있던 것을 발견하게 되고 더 좋은 아이디어가 떠오르게 되기도 합니다. 또, 얘기를 하다 보면, 사람들이 여러가지를 물고 늘어지면서 시비를 걸게 되는데, 이런 점에 대해서 미리 대답을 생각해 보고 하면 실제 논문심사시에도 훨씬 여유가 있게 됩니다. 결국 논문심사를 위해 여러분이 준비해야 할 것은 이런 질문에는 이렇게 대답하고, 저런 질문에는 저렇게 대답하고.. 등을 미리 생각해 놓아야 하는 것인데, 당연히 예상문제를 많이 풀어보고 들어가는 것이 유리합니다. 그러니 다른 사람과의 discussion은 많으면 많을수록 좋습니다.
보통 어떤 논문에 대해서 눈여겨 보는 것은,
1. 어떤 환경 혹은 시나리오를 가정하고 있는가?
2. 가정하고 있는 환경에서 어떤 문제가 있는가?
3. 그 문제가 왜 중요한 문제인가?
4. 문제 해결을 위한 본인의 아이디어는 무엇인가?
5. 같은 문제 해결을 위해 다른 사람들이 기존에 한 일은 무엇인가?
6. 다른 사람들이 한 일과 본인이 한 일이 *객관적*이고 *정량적*으로 잘 비교, 분석되었는가?
7. 혹시 나빠지는 점은 없는가?

등등입니다. 위의 물음에 대해 자신을 가지고 다른 사람을 설득할 수 있으면 됩니다.
제 개인적으로, 석사논문의 수준은 웬만한 conference에 accept될 수 있는 정도면 적당하다고 생각합니다. 이 말은 바꿔말하면, 여러분이 작성하는 석사논문이 웬만한 conference의 심사위원들을 설득할 수 있는 정도의 수준이 되어야 한다는 뜻입니다.

세미나 참석 (version 0.2 추가)

아이디어를 얻기 위해서 또 하나 강조하고 싶은 것은 세미나 참석입니다. 보통 대학원 연구실 배정을 받고 나면 언제부터 본인에게 연구분야가 있었다고 자기 연구분야가 아니면 세미나에 흥미조차 없는 사람들이 많습니다. 그러나, 앞으로 여러분이 어떤 일을 하게 될지 모르고, 그런 기회가 아니라면 다른 분야에서 어떤 일을 하는지 조차 모르게 되니 가급적 학과/학교에서 열리는 세미나에는 시간을 내어 참석하기 바랍니다. 그 시간에 여러분이 논문을 하나 읽는 것보다, 해당 분야에 대해서 잘 정리해서 발표해 주는 세미나를 듣는 것이 훨씬 도움이 됩니다.
그리고 결국 전산학에서 어떤 문제를 풀기 위한 approach는 거의 비슷하기 때문에, 다른 사람들이 어떤 문제를 어떤 식으로 풀어나갔는지를 보는 것이 많은 도움이 됩니다. 그리고 어떤 경우에는 전혀 다른 분야에서 쓰는 방법을 내 분야에 적용시켰을 때 매우 효과적인 경우도 많습니다. 따라서, 아무리 다른 분야의 세미나라 하더라도 세미나를 들으면서 자유롭게 내가 알고 있는 분야에 비슷한 문제는 없는지 등을 생각해 보는 것이 좋습니다. 내용을 모르더라도 최소한 발표는 어떻게 하는 것이 좋겠는지, 혹은 질문에 대해 어떻게 대처해야 하는지 등에 관해서라도 배울 수 있는 이점이 있으니 세미나 참석은 중요합니다. 같은 이유로 대학원 때 수업도 본인의 연구 분야에 관련된 부분만 집중해서 듣지 말고, 다른 분야의 과목들을 듣는 것을 권장합니다.

흔히, 박사학위의 기본 요건 중의 하나가 T자형 인간이라고 합니다. 그러니까 전산학 전 분야에 대해서 breadth와 자기 분야에서의 depth를 가져야 한다는 것이죠. 보통 자격고사(qualifying exam)를 통해 breadth를 테스트 하고, depth는 박사학위논문심사에서 따지게 됩니다. 우리 학교의 경우 자격고사가 제 역할을 하고 있지 못해서 좀 문제이기는 하지만.. 아뭏든 둘 다 중요하니 자기 분야의 depth만 고집할 게 아니라, 다른 분야에서 어떤 일들이 일어나고 있는지도 관심을 가지고 살펴보기 바랍니다. 그게 다 피가 되고, 살이 됩니다.

----

쓰다 보니 조금 훈계조로 흐른 부분도 없지 않고, 일부는 몇몇 사람에게 얘기한 적도 있는데.... 정리하는 차원에서 쓴 것이니 참고하기 바랍니다. 또 다른 생각이 나면 지속적으로 업데이트 하도록 하겠습니다.

아래는 참고할 만한 링크입니다.

Useful Links on Graduate Studies, Research, and Technical Communication

Graduate School Survival Guide (by Wanda Pratt)

Guides to Surviving Computer Science Graduate School (by Ronald Azuma)

Advice on Research and Writing

Graduate Studies, Research and Careers in Computer Science

An Evaluation of the Ninth SOSP Submissions or How (and How Not) to Write a Good Systems Paper

How to Have a Bad Career in Research/Academia (Also at David Patterson's homepage)

Resources for Writers and Writing Instructors (by Jack Lynch)

임재춘의 과학기술자 글쓰기

DS2411

2009-09-24T06:17:00.000-07:00

특징
DS2411은 MAXIM에서 제조하였으며, Vcc 입력 기능이 있는 실리콘 시리얼 넘버를 포함하고 있다. 제조시 레이저로 식각된 테스트를 거친 고유한 64비트 등록번호(8비트 제품코드 + 48비트 시리얼 넘버 + 8비트 CRC 테스터)를 가지며, 이들 부품이 서로 중복되지 않도록 보장한다. 1uA 미만의 대기 전류를 사용하며, 멀티드롭 컨트롤러가 내장되어 있어 공통 1-Wire 네트워크 상에서 다중 DS2411 상주가 가능하다. 8비트 제품 코드로 1-Wire 마스터에 DS2411 소자의 식별이 가능하며, 저가형 TSOC, SOT23-3 및 플립 칩 표면 실장 패키지로 마이크로프로세서의 단일 포트 핀에 직접 연결하고 최대 15.4Kbps 속도로 통신한다. 또한, 125Kbps의 통신 속도를 제공하는 오버드라이브모드를 지원한다. DS2411 소자의 동작범위는 1.5V ~ 5.25V이며, -40'C ~ +85'C에서 동작한다.

설명
DS2411 실리콘 시리얼 넘버는 외부 전원으로 동작하는 저비용 전자 등록 번호이다. DS2411은 최소의 전자 인터페이스(일반적으로 마이크로컨트롤러의 단일 포트 핀)를 통해 판별할 수 있는 절대적으로 고유한 48비트 시리얼 넘버, 8비트 CRC 및 8비트 제품 코드(01h)로 구성된다. 데이터는 Dallas Semiconductor의 1-Wire 프로토콜을 통해 직렬로 전송된다. 외부 전원은 소자의 동작 전압 범위를 일반적인 1-Wire 소자 미만으로 확대하는데 필요하다.

동작
DS2411의 등록번호는 단일 데이터 라인을 통해 엑세스 된다. Dallas 1-Wire 프로토콜을 사용하여 48비트 시리얼 넘버, 8비트 제품 코드 및 8비트 CRC가 검색된다. 이 프로토콜은 I/O 핀 상에서 버스 마스터에서 발생된 하강 에지인 지정된 타임 슬롯 동안 버스 상태와 관련하여 버스 트랜잭션을 정의한다. 모든 데이터는 최하위 비트부터 읽혀지고 쓰여진다. DS2411은 Vcc 파워 업과 초기 1-Wire 통신 사이에 tpwrp(1200us) 만큼의 지연을 필요로 한다. 이 시간 동안 소자는 존재 검출 펄스(presence-detect pulse)를 발생시킬 수 있다.

SenWeaver

2009-09-16T21:34:00.000-07:00

지역 IT특화연구소인 유비쿼터스신기술연구센터(UTRC 센터장 김희철)가 USN분야 응용소프트웨어 개발 기간을 획기적으로 단축할 수 있는 SW인 ‘센위버(SenWeaver)’ 플랫폼을 개발했다고 4일 밝혔다.
센위버 플랫폼은 센서노드 상에서 구동되는 센서 운영체제와 네트워크 프로토콜, 노드 응용개발도구, 네트워크 관리도구 등의 개발환경과 도구를 하나의 틀로 제공하는 시스템이다. 기업들이 응용소프트웨어 개발에만 집중할 수 있도록 함으로써 신뢰성 있는 센서네트워크 관련 솔루션을 개발 및 구축할 수 있게 한 제품이다.

센위버는 센서네트워크 플랫폼의 선두그룹인 카네기멜론대의 ‘나노-RK’나 하버드대학의 ‘Pixie’은 물론, 미국 아크록과 더스트 네트워크사의 플랫폼과 비교해 기술적인 우위가 있는 것으로 평가받았다.
김희철 센터장은 “이번에 개발된 센위버 플랫폼은 플랫폼 네트워크 산업인 스마트 산업의 핵심 수단이 될 것”이라며, “앞으로 기업들이 USN관련 다양한 응용소프트웨어를 개발할 수 있는 기반이 될 것”이라고 말했다.

UTRC는 지난 2006년 12월 대구대학교 내에 설립된 IT특화연구소다. 박사급 연구원 8명을 포함, 총 30여명의 전문연구원이 RFID/USN관련 연구를 진행하고 있다.

http://www.senweaver.co.kr/ 센위버
http://www.utrc.re.kr/ UTRC

- 09.08.05 etnews -

Effective Link Abstraction for Wireless Sensor Networks

2009-09-06T20:01:00.000-07:00

1. Message Pool. The message pool has been invaluable for storing messages until a later point in time that they can be sent. It decouples the power management policy from the data transmission policy, which in turn means you can submit a message whenever you want and it will go out on the radio.

2. Message Futures. Due to the decoupling above, message futures are necessary if you generate more than one message per power cycle. Keeping a queue (we use cqueue by Cory Sharp) in the networking protocols allows each protocol to decide how deep the queue is and how to prioritize it. This can also be accomplished with a buffer pool that network protocols share and extract buffers when needed.

3. Neighbor Table. Moteiv doesn't use the Neighbor Table for storing link estimates, instead we've found its usefulness in maintaining power schedules. The neighbor table makes it easy for the link to either insert schedule or the network protocol (such as NetSync and NetWake in Boomerang) to add other schedules.
One shortcoming--We will be changing the interface to comply more with TEP102 for timers. Currently the neighbor table takes a 32-bit absolute time for turning the radio on and off. Because TinyOS is not real-time, delays can cause an event to be missed, and lead to 36-hour delays (32-bit rollover)! The solution is the TEP102 proposal for Alarms--use t0 and dt to specify the next wakeup interval. This then couples nicely with the Timer/Alarm system and makes the overall implementation easier.

4. Link Estimation turns out to be a bit of bust because you can't do it very well in an application-independent manner. Jack Stankovic pointed out at one of our meetings that different applications have different opinions on what a high-quality link is. Cost-based routing is one thing, but geographic or sensor-based routing has different requirements. Link estimation in the base case doesn't have to be fancy, nor does it have to give me "real units" like dBm or PER, relative link estimates are just fine for all the protocols we've encountered.

5. Reliability. I don't care how you implement reliable transport at the link, but you need to give protocols the option to ask for reliability and get feedback as to whether the reliability was achieved. This point should be obvious, but it is absolutely critical for us to have bi-directional reliability data to make informed decisions about what to do with the next message.

6. Timestamping. I've never figured out why Timestamping is not a core piece of metadata available with each packet in the default implementations of TinyOS. It is trivial to provide a timestamp either on an SFD, or when SFD isn't available, on the packet dispatch. Sure, it won't be 100% accurate, but with a 30.5us clock it doesn't really matter. The #1 best addition to SP in Boomerang was timestamping, and has served us very well.

7. Naming. This is an overrated topic. We initially thought we were going to implement Arsalan's SP handle idea, where each link address is given a virtual handle for network protocols to use to decouple the link address (size, interface, type, etc) from the network decisions.. Then we starting looking at the realities of the situation and decided that, in practice, it was never going to be needed and could easily be pulled in if we needed it at a later date. There was no point confusing users with a handle when they're still trying to figure out what "address" means.

8. Congestion. Clearly this isn't completely important from a practical perspective. From a research/academic perspective it was quite fascinating to see we could build some congestion control schemes that had basic working properties in a platform/link independent manner. I still am fascinated by that, but practically speaking--our motes are off most of the time and our goal is to do as little data transfer as possible, so 99.9999% of the time there is no congestion.

9. Phase/Delay feedback. Not necessary with the message pool decoupling transmission from the network protocols. David Culler and I initially thought that this was a requirement for the decoupling, but experience with SP has shown that the message pool can do an effective job of the decoupling without complicating the other protocols with additional phase/delay feedback.

10. Urgent. I think this is somewhat useful and doesn't need to have more than 1-bit of information. There's a number of papers out there, including one from Stankovic, that talk about how 1-bit of information can provide effective prioritization of network traffic. Arbitrary numbers of priority levels, in my opinion, are complex and aren't required by any existing protocols. The wireless sensor system is supposed to work together--if you are worried about resource constrained systems fighting internally with themselves, you're probably developing your application incorrectly.

11. Abstract data types. The initial version of SP required you to specify the fields in the message structure itself by directly accessing them. Phil Levis was right in complaining that it led to a lot of programmer error. In SP in Boomerang, we moved to a system where we explicitly prohibited users from editing any of the fields of an sp_message_t structure. Instead, you set fields using the SPSend.send() and SPSend.sendAdv() commands, and access fields through the SPMessage interface of SPC. This is a much safer implementation and has reduced the number of headaches that we encountered in the initial implementation of SP for the Sensys paper.

12. Receive. We completely threw out the TinyOS method of Receive where you must return a message pointer and we introduced a new interface, SPReceive, that can fan out to as many protocols as you need. This has been a time and bug saving development. The notion is the following: If you need data in the received message, you must copy or do something with it before returning from the SPReceive.receive() function. The buffer passing mechanism of ReceiveMsg in the main TinyOS distribution, although novel in principle, just wasn't used in practice.

- Joe Polastre -

UART0

2009-09-02T21:05:00.000-07:00

TinyOS에서 telosb 계열은 UART1을 기본 포트로 지정되어 있으므로 UART0을 사용하기 위해서는 다음과 같이 트릭을 써서 해결한다.

HPLUARTC.nc 파일의 내용을 수정한다.
경로는 /opt/tinyos-1.x/tos/platform/telos

components HPLUARTM, HPLUSART1M as HPLUSART;
--->
components HPLUARTM, HPLUSART0M as HPLUSART;

로 변경한다.

Synchronized Low-power Protocol

2009-08-30T21:29:00.000-07:00

동기 방식 저전력 프로토콜은 멀티홉 네트워크에서 time sync를 유지하면서 active/sleep 스케줄링을 하도록 설계되어 있다.
32KHz로 동작하는 자신의 타이머를 이용하여 time stamp를 얻고, 자신의 시간 정보를 broadcasting한다. 시간 정보를 담고 있는 sync 메시지를 받은 노드들은 자신의 시간 정보와 수신된 시간 정보를 비교하여 업데이트한다.

routing message : minimum cost를 계산하여 route-path를 설정하기 위한 메시지
sync message : 시간 동기화를 위한 메시지로 자신의 시간 정보를 브로드캐스팅
period : active/sleep 주기를 설정
duty cycle : 한 주기 동안 동작 가능한 비율

period가 길고 duty cycle이 큰 경우 좋은 성능을 나타낸다.

다음의 원문은 주기를 이용한 duty cycle 적용 방법이다.

Boomerang lowpower works upon the principle of synchronised global time known to all motes in the network. All synchronised motes then go to sleep and wake up at the same time (duty cycle). All messages are sent/received within this duty cycle. Messages queued to sending outside this time are simply buffered until the next duty cycle.
In Boomerang this is managed by 2 components, netSync which handles global time and netWake which handles the wake/sleep mechanism.

If you have access to a Boomerang environment, run the Trawler application compiled for lowpower. There you can see that messages may arrive at an inconsistent rate, but they all arrive eventually.
Boomerang allows you to change the duty cycle via the lowpower parameter of make.
The NETSYNC_PERIOD_LOG2 macro allows you to change the time between listening periods

by default NETSYNC_PERIOD_LOG2 is 16 i.e. 2**16 ticks of the 32khz clock is 2 seconds. Default lowpower is 5% .
5% of 2 seconds is 100msecs. So by default you listen for 100msecs every 2 seconds.
Suppose I want 100sec every 4 seconds, set NETSYNC_PERIOD_LOG2 to 17 ( 4 seconds) and lowpower to 3 (3% of 4 seconds = 120msec)

Add the following line to your makefile

ifeq ($(filter netsync_period_log2,$(MAKECMDGOALS)),netsync_period_log2)

then do

make lowpower,3 netsync_period_log2,17

xubuntu에서 압축 해제

2009-08-27T02:06:00.000-07:00

tar 압축 파일 중 노틸러스에서 자동으로 압축이 풀리지 않는 파일이 간혹 있다.
이 경우 터미널을 이용하여 압축을 해제하면 된다.

tar로 생성된 파일은
# tar xvf

tgz나 tar.gz는
# tar xvfz

와 같이 하면 된다.

MAC ack & retransmission

2009-08-26T22:56:00.000-07:00

retransmission 기능을 사용할 때는 AMPromiscuous + Queue 조합을 사용하는데, 1hop adhoc mode의 경우는 이것이 불필요할 뿐더러 programmer-controllable하지 않은 부분이 추가되는 단점이 있음. 따라서 AMStandard component를 사용하면서 retransmission을 적용하는 것이 필요하다.

reliability를 높이기 위해 retransmission 기능을 사용하고자 할 때는 다음과 같이 설정한다.

0. 설정

/opt/tinyos-1.x/tos/lib/CC2420Radio/CC2420RadioM.nc에서 bAckEnable = TRUE;로 설정
/tos/system/AMPromiscuous.nc에서 crc_check = TRUE;로 설정
/tos/lib/Queue/QueueSendM.nc에서 retransmit = TRUE;로 설정

1. Application에서 MacControl Component를 wiring
        configuration Test {
        }
        implementation {
           component CC2420RadioC;
          ...
           TestM.MacControl -> CC2420RadioC;
        }

2. StdControl.start() 에 MacControl.enableAck() 을 추가
      module TestM {

          provides {
          ...
          }
          uses {
             interface MacControl;
              ...
          }
         implementation {
            ...
            command result_t StdControl.start() {
            call MacControl.enableAck();
            }
            ...
         }

3. tos/lib/CC2420Radio/CC2420RadioM.nc

BackoffTimerJiffy.fired() 에서 case TIMER_ACK 의 if (!post PacketSent()) 를 주석처리. 이것 때문에 ACK이 오지 않더라도 ack timeout 시 sendDone에 SUCCESS가 return된다.
sendDone event callback에서 success == FAIL 인 경우 바로 msg ptr을 retransmission. 필요에 따라 retransmission counter를 두고 max_retransmission을 초과할 경우 drop

4. 멀티 홉 과 재전송 기능을 사용할 경우에 발생하는 문제 및 해결 방법

opt/tinyos-1.x/lib/Queue/QueuedSendM.nc 는 TinyOS의 메시지 전송 큐를 관리한다. 재전송 기능도 QueuedSendM 에서 수행된다.

event result_t SerialSendMsg.sendDone[uint8_t id](TOS_MsgPtr msg, result_t success) {
...
if (!retransmit \\ msg->ack != 0 \\ msgqueue[dequeue_next].address == TOS_UART_ADDR) {
// 재전송이 필요 없는 경우 큐의 포인터를 다음 패킷으로 이동시키고,
// 상위 컴포넌트로 메시지 전송 성공 이벤트 발생 (signal, SUCCESS)
...
} else {
...
if ((++(msgqueue[dequeue_next].xmit_count) > MAX_RETRANSMIT_COUNT)) {
// 최대 재전송횟수를 초과했을 경우 큐의 포인터를 다음 패킷으로 이동시키고,
// 상위 컴포넌트로 메시지 전송 실패 이벤트 발생 (signal, FAIL)
...
}
}
// 데이터 전송 Task 실행
post QueueServiceTask();

return SUCCESS;

}

테스트는 멀티홉 라우팅 기능을 사용하며, 라우팅 경로를 빨리 설정하기 위해 라우팅 메시지 전송 주기를 짧게 설정하였다. 그리고 모트 3개 정도에 프로그램을 올리고 테스트 한 결과 재전송이 계속 발생하지만 Base Node에 패킷이 수신되지 않는 현상이 발생하였다. 문제의 원인을 파악한 결과, 라우팅 메시지는 Broadcast 를 사용하며 Broadcast도 이 QueuedSend 의 큐를 통해 전송이 일어나고, Broadcast에 대해서도 재전송을 수행하기 때문이었다.
따라서 위 소스를 그대로 사용하여 재전송 기능을 사용할 경우, Broadcast 하는 패킷에 대한 Ack 가 없을 경우에도 계속 재전송을 하게 되어 Breadcast가 많을 경우 Queue Overflow가 발생할 수 있으며, 쓸데 없이 계속 재전송을 수행하게 된다.
(※ 수신 노드에서는 unicast 일 경우에만 ack 메시지를 전송한다)
이 문제를 해결하기 위해서 위 소스의 if 문 조건을 다음과 같이 변경하여야 한다.

if ((!retransmit) \\ (msg->ack != 0) \\ (msgqueue[dequeue_next].address == TOS_UART_ADDR) \\ (msgqueue[dequeue_next].address == TOS_BCAST_ADDR)) {
...
}

Sensor...

2009-08-25T08:03:00.000-07:00

센서 노드에 탑재되어 있는 센서들은 보통 14bit ADC, 또는 12bit ADC를 가지고 있다.
이는 표현할 수 있는 한계를 의미하는데 SHT11의 온도센서의 경우 14bit로 4800까지 표현이 가능하다. 하지만 더 큰 값도 간혹 나오기도 한다. 12bit ADC를 사용하는 센서는 2의 12승, 즉 4096까지 출력 된다.
더욱 큰 값을 출력하고자 한다면 12bit보다 좋은 ADC를 연결하면 가능하다.

Packet Loss...

2009-08-25T02:13:00.000-07:00

telosb 계열의 모트에서 사용되는 라디오 모듈인 CC2420 RF Chip은 802.15.4 규격에 의해 2.4GHz 대역에서 250Kbps의 최대 통신 속도를 가진다. 그러나 이는 통신(전파) 환경이 깨끗한 상태에서의 1:1 통신의 경우에 해당된다. tinyos는 기본적으로 csma/ca방식을 사용하여, 현재 RF채널이 사용되고 있는지 확인 후 없으면 얼마의 시간지연 후에 데이터를 전송하게 된다.
예를 들어, 100 bytes의 데이터를 전송하는데 약 3 ms의 시간이 걸리는데, 데이터 전송 전에 필요한 Random Backoff 시간과 RF와 CPU간의 통신 및 레지스터 설정 등의 시간을 고려할 경우 약 5ms 정도의 전송 시간이 필요한 것이다.
멀티홉으로 통신하는 경우에는 센서 노드가 서로에게 영향을 줄 수 있다. 즉, 시간 지연이나 패킷 손실을 일으킬 수 있다. 특히 중간단에 위치한 노드들은 말단에 위치한 노드들이 보내는 패킷을 모두 수신하고, 이를 또 상위 노드에 전송하므로 여기에서 손실이 발생할 가능성이 매우 크다. 또한, Radio의 경우와는 다르게 UART의 손실이 발생할 가능성도 있다. UART의 통신 속도등이 패킷 손실을 불러올 수도 있다.

http://www.ee.kth.se/php/modules/publications/reports/2005/2284.pdf http://www.cs.berkeley.edu/~arsalan/Papers/PacketDelivery_Poster.pdf

T1에서의 ADC Mapping

2009-08-25T00:53:00.000-07:00

ADC를 사용할 때 주요 인자가 2가지가 있다.
reference 전압과 resolution 이다. mica 시리즈에서 사용되는 atmega128L의 경우 보통 reference 2.56V, resolution은 10bit를 사용하는데, telos 계열에 사용되는 msp430의 경우 reference 1.5 or 2.5V, resolution은 12bit를 사용한다. 따라서 mica 계열로 했을 때와 telos 계열로 했을 때의 ADC에서 읽히는 Raw값에 대한 전압계산식은 다르다.

다음은 ADC를 매핑하는 예이다.
ADCC 컴포넌트를 사용하여 ADCControl 인터페이스와 bindPort 커맨드를 이용한다.
========================================================================
** Test.h **
#include "MSP430ADC12.h"
enum {
TOS_ADC_TEST_PORT = unique("ADCPort"),
TOSH_ACTUAL_ADC_TEST_PORT = ASSOCIATE_ADC_CHANNEL ( INPUT_CHANNEL_A0, REFERENCE_VREFplus_AVss, REFVOLT_LEVEL_2_5),};

#define MSP430ADC12_Test ADC12_SETTINGS( \ INPUT_CHANNEL_A0, REFERENCE_VREFplus_AVss, SAMPLE_HOLD_4_CYCLES, \ SHT_SOURCE_ACLK, SHT_CLOCK_DIV_1, SAMPCON_SOURCE_SMCLK, \ SAMPCON_CLOCK_DIV_1, REFVOLT_LEVEL_1_5)

** Test.nc **
configuration Test {
}
implementation {
components Main, TestM, ADCC;
Main.StdControl -> TestM;
TestM.ADC -> ADCC.ADC[TOS_ADC_TEST_PORT];
TestM.ADCControl -> ADCC;
}

** TestM.nc **
module TestM {
provides interface StdControl;
uses interface ADC;
uses interface ADCControl;
}
implementation {
command result_t StdControl.init() {
call ADCControl.init();
call ADCControl.bindPort(TOS_ADC_TEST_PORT, TOSH_ACTUAL_ADC_TEST_PORT);
return SUCCESS;
}
.....
}

zigbee & tinyos

2009-08-25T00:17:00.000-07:00

제목대로 둘의 관계는 본질적으로 다른데 웹을 뒤적거리다 보면 터무니 없는 이야기가 많아서 자칫 헷갈리기 쉽다.
그래서 이 둘을 파헤쳐 본다.
이 둘의 관계를 좀 더 명확히 하자면 IEEE 802.15.4 (PHY와 MAC) 표준에 zigbee를 사용하는지 tinyos를 사용하는지가 다르다면 다르다.

먼저 zigbee와 IEEE 802.15.4의 관계를 보자.
zigbee 표준 = IEEE 802.15.4 + zigbee spec
IEEE 802.15.4 = PHY + MAC
zigbee spec = NWK + APS + (security, ZDO)

그렇다면 tinyos는
tinyos = IEEE 802.15.4 + tinyos
IEEE 802.15.4 = PHY + MAC
tinyos = OS + (MAC) + APS

위와 같이 구성된다.

Node ID

2009-08-24T23:58:00.000-07:00

식별 가능한 Node ID는 0~65565 까지 지정해서 사용이 가능하며, 보통 0번은 베이스 노드로 사용한다.
보통 센서 노드의 ID를 부여하는 방법은, 인스톨할 때 뒤에 숫자를 붙여서 노드 ID를 부여한다. 그러나 이것은 어디까지나 임시적인 방법이다. 즉, 다른 노드들도 같은 ID를 가질수가 있기 때문이다. 이런 것을 Short Address 라고 해서 RF통신상에 트래픽을 줄이기 위해 사용한다. IEEE 802.15.4에서는 이 Short Address 외에 64bit의 고유주소를 사용한다. (EUI64) 비슷한 예로, 보통 인터넷에서 IP주소 외에 실제적으로 통신하기 위해 쓰이는 NIC 고유주소가 있는데, (이것도 MAC주소 혹은 번호라고 보통 칭한다.) 그것은 그 네트워크장치가 다른 어떤 장치와도 같지 않음을 보장해야 한다. 그래서 IEEE에서 일정부분의 일련번호를 받은 제조회사가 그 나머지 부분에 대해 겹치지 않도록 하여 제품 생산시에 기록하게 된다. 센서네트워크에서도 64bit의 주소를 용하는데 그 중 앞의 24bit는 IEEE에서 부여받은 번호를 나머지 40bit는 제조회사가 겹치지 않도록 부여 한다. 모트의 경우, 보통 이러한 40bit에 대해 제조사가 일일이 번호를 부여하기 어려우므로, DS2411과 같이 고유의 ID를 가진 칩을 사용하여 이 칩이 가지고 있는 일련번호와 제조회사과 부여받은 번호를 합쳐서 사용하게 되는데 이를 이용하면 된다. 하지만 현재 센서 네트워크 시장규모나, 성장의 규모로 볼 때, 아직 이러한 고유번호들은 사용이 미흡한 상태이다.

- maxfor -

atomic

2009-08-24T19:15:00.000-07:00

NesC에 자주 볼 수 있는 키워드 중에 atomic 이 있다.
atomic은 race condition을 막기 위해 존재한다.

race condition이란, 인터럽트에 의해서 발생하는
비동기적 코드들이 갑작스럽게 사용중인 전역변수에
접근하는 일이 발생했을때 일어나는 충돌을 말한다.

해결방법은 다음과 같다.
- 전역변수를 사용하지 않는다.
- 인터럽트를 사용하지 않는다.
- 되도록이면 코드를 짧게 구성한다.
- atomic키워드를 사용한다.

여기서 atomic코드는 모든 전역변수의 값을
정의할때,

atomic {
var1 = var1 + 1;
var2 = var2 -1;
}

이렇게 하게 되면, 만약 이 데이터를
처리 도중에 다른 인터럽트가 발생한다고 해도 이 데이터에
대한 선점권이 넘어가지 않으므로, 충돌은 일어나지 않게 된다.

Timer에 대한 진실(?) 혹은 거짓(?)

2009-08-21T00:48:00.000-07:00

타이머가 매 3분 마다 호출되어도 매번 데이터를 전송하지는 않는다. 이는 통신 과정 중간에 task처리 과정과 rf 전송을 위해 경합하는 과정도 있기 때문에 고정된 시간에 데이터를 전송하는 것은 어렵다.

[TIP]
1024ms = 1 second
60 second * 1024ms = 61440ms(1 minute)
3600 second * 1024ms = 1 hour

센서 노드의 H/W 동작 범위

2009-08-21T00:42:00.000-07:00

CC2420 : 2.1v ~ 3.6v
MSP430 : 1.8v ~ 3.6v
SHT11 : 2.4v ~ 5.5v

tinyos check

2009-08-21T00:22:00.000-07:00

#/opt/tinyos-1.x/tools/script
#./toscheck

How to convert RSSI value to dBm?

2009-08-18T22:57:00.000-07:00

Convert the unsigned raw counts (x) to a signed integer (y).

If x < 127; y = x
If x > 127; y = x - 256

Convert the signed counts (y) to RSSI in dBm, subtract -45 dBm
RSSI = y – 45 dBm

Example:
Raw Counts = 217
Convert to signed integer : 217 – 256 = -39
Calculate RSSI (dBm) : -39 – 45 = -84 dBm

MSP430F1611 Clock

2009-07-27T06:04:00.000-07:00

MSP430 클럭은 ACLK, MCLK, SMCLK로 구분된다.
ACLK는 외부클럭을(32.768KHz) 사용하고 있다.
MCLK, SMCLK는 내부 DCO를 사용하고 있으며 기본 4MHz 동작하며
최대 8MHz까지 설정이 가능하다.

TinyOS를 사용하는 경우 클럭 설정은
/opt/tinyos-1.x/tos/platform/msp430/MSP430ClockM.nc
에서 확인 및 설정할 수 있다.

강의에 대한 10가지 이야기.

2009-07-27T05:42:00.000-07:00

1. 처음부터 강의를 하지 않는다.
먼저 강의자와 청강자는 처음 보는 사람이다.(처음 보는 사람이 아니라도 그 강의를 시작하는데 있어서는 항상 처음이라 할 수 있다.) 무턱대고 강의를 시작하자면 둘다 준비된 상태가 아니기 때문에 강의의 내용이 바로 귀에서 머리로 전달되는데는 시간이 필요하다. 당신의 목소리가 청강자의 귀에 익숙해질 시간이 필요하다. 기기를 작동할때도 30분간 미리 작동을 시키고 실험을 할때도 예비가열을 하듯이 당신의 목소리에 익숙하질 시간이 필요하다. 간단한 자기소개로 우선 말을 꺼내고 (갑자기 봄이 와서 옷입기가 난감하다는지. 오는데 전철에서 이상한 변태를 보았다는지 등의 흔히 접하고 누구나 공감하지만 재미있는 화재) 언급한후 강의를 시작한다.

2.목차와 중요성 언급
강의를 하는데 어떠한 순서에 의해 이야기를 할것인지 이야기하고, 이 강의의 중요성에 대해 언급한다.

3. 산을 본후 나무를 보자.
내용은 전반적인 흐름을 먼저 이야기한 다음 세부사항으로 들어가도록 한다. 하나하나 세부사항을 먼저 언급하다보면 머리에 개념을 잡기 어려우니 포괄적인 면을 먼저 설명후 세부사항으로 들어가도록 한다. 세부사항을 설명할 때는 적절한 예를 제시하여 이해가 쉽게 되도록 한다.

4. 단락이 나누어지는 지점에서 확인 절차
1단계에서 2단계로 설명이 들어가기 전 지금까지 어떠한 부분에 대해 설명을 하였고, 여기서 잊어서는 안될 부분에 대해 한번씩 집고 넘어간다. 전체를 다 설명한 후에는 다시 한번 목차에 대해 언급을 하며, 오늘 강의 내용에 대해 청강자와 함께 정리하는 순서를 가진다. 설명한 내용에 대해 단락이 끝날때 요점을 정리하라 말했었는데, 청강자의 답변을 기다려서 강의에 참여할 수 있게 한다.

5. 질문을 받는다.
당신의 능력을 보여줄 차례이다. 그런데 혹시 난감한 질문이 들어온다면 아주 좋은 질문이라고 말한후 대략적 설명만 한 후 내용이 너무 길고 할당된 시간으로 인해 메일로 보내주시면 답변을 드리겠다는 식으로 위기를 모면해라.

6. 시간을 잘쪼개자.
명강의자의 경우에는 단락별 시간을 딱딱 나누어 설명한다. 그러나 흐름이 깨지지 않도록 하기 위해 세심한 부분도 유념하기도 한다.

7. 말로 전부 강의를 하려고 하지마라.
시각적 효과도 필요하다. 빈공간을 채우기도 힘들고 빈공간에 다 채우자면 너무 지루하고 괴롭다. 공감각적이면 더욱 좋겠다. 만질 수 있고 볼 수 있는것 말이다. 시각적인 표현은 슬라이드나, OHP를 사용하는데 OHP를 사용할 경우 너무 문자가 많고 디테일하기보다 계략적인 부분만 보여주고 나머지는 말로 설명한다. 결론적으로 말하자면 OHP는 키워드 중심으로 만든다. 공감각적 표현은 설명하는 내용에 관련된 제품을 보여주고 돌아가면서 자세히 볼 수 있도록 하는 방법 인데 자칫 잘못하면 강의가 어수선해질수 있으니 조심해야한다.

8. 강의자의 목소리 톤도 중요하다.
솔음이 가장 좋다고 하지만 그렇다고 억지로 올려서 서비스 직원이 된듯하게 될 경우라면 그냥 원래대로 해라. 하지만 목소리는 커야 한다. 부가적으로 의상과 인상도 추가된다.

9. 멘트를 작성한 다음 혼자 강의를 해봐라.
멘트만 보고 강의하는 자는 정말 매력없다. 강의의 흐름과 지식은 이미 알고 있는 상태이니청강자와 눈을 마주치며 강의 하도록 하자. 어떤 사람은 혼자 빈강의실에서 강의를 했다는 사람도 있다. 글로 작성한 것과 말로 표현하는 것은 조금 다르다. 작성후 혼자 꼭 !!! 강의해봐라.

10. 예시
안녕하세요. 저는 오늘 어려분에게 알파벳에 대해 강의를 하게된 파직스입니다. 오늘 날씨 너무 좋죠? 이런 날 벗꽃 구경이라도 가야 하는데 여러분들도 마음이 싱숭생숭하시겠지만 놀러가지 못하고 강의 준비하느라 노력한 착하고 불쌍한 저를 위해 경청해 주실거라 믿고 강의 시작하겠습니다. (이보다 길게 맨트를 준비한다. 약 5~10분정도로 이 작업이 목풀기 작업)아까 말씀 드렸던 바와 같이 오늘 저는 알파벳이라는 것에 대해 강의를 하겠습니다. 알파벳은 영어를 하려는 최소의 단위로 영어의 구성원이라 할수 있겠지요. 조금 말이 어렵지요? 예를 들어 ...

enum으로 선언한 변수의 값

2009-07-22T21:31:00.000-07:00

enum은 상수 열거형 지시어다.
그 안에 상수정의가 특별한 값에 대입되어 있지 않다면 0부터 차례대로 자연수의 값을 갖는다.
또한, enum{}으로 선언한 변수는 컴파일러에서 16비트로 기억된다. 즉, int16_t로 선언된다.
enum {TIME = 61440}; 으로 하고 컴파일을 하게 되면 "warning: decimal constant is so large that it is unsigned" 라는 주의 메시지가 뜬다. 해당 값이 int16_t 에 담기에는 너무 크다고...
컴파일러는 똑똑해서 자기가 알아서 unsigned로 바꿔준다.
하지만 이게 보기 싫다면 해당 값의 끝에 "U"를 붙여 주면된다.
enum {TIME = 61440U};
이렇게 하면 unsigned라고 미리 알려주므로 warning은 뜨지 않는다. 보다 큰 숫자를 입력하고 싶다면 마찬가지로 해당 값의 끝에 "L"을 붙여 사용하도록 한다.
enum {TIME = 6144000L};

TI(Texas Instruments) - Zigbee Protocol Stack

2009-07-18T06:29:00.000-07:00

TI(Texas Instruments)에서 Z-stack을 공개.

http://focus.ti.com/docs/toolsw/folders/print/z-stack.html

moteiv's boomerang

2009-07-18T06:14:00.000-07:00

http://docs.tinyos.net/index.php/Boomerang

boomerang 2.0.1은 2006년 3월 처음 릴리즈되었으며, 현재 boomerang 2.0.4까지 다양한 버그를 수정하여 릴리즈되었다.

boomerang 의 핵심은 간단하게 구현된 저전력 메시 네트워크의 형태인 Delta 어플리케이션으로 소규모 네트워크에서 빠른 응답을 한다.
내부적으로 큐를 사용하여 이웃 노드의 테이블을 관리하고, 이웃 노드들의 LQI 및 재 전송과 같은 형태의 알고리즘(?)을 사용하여 네트워크의 신뢰성을 보장하고, 에너지 효율적인 동작을 하도록 구현되어있다.

Output Power Configuration for the CC2420

2009-07-13T23:57:00.000-07:00

▶ Output Power Configuration for the CC2420

Power Level Current Consumption(mA) Output Power(dBm)
0x1f(31) = 17.4mA = 0dBm
0x1b(27) = 16.5mA = -1dBm
0x17(23) = 15.2 mA = -3dBm
0x13(19) = 13.9mA = -5dBm
0x0f(15) = 12.5mA = -7dBm
0x0b(11) = 11.2mA = -10dBm
0x07(7) = 9.9mA = -15dBm
0x03(3) = 8.5mA = -25dBm

**거리가 멀수록 값이 작아지며, 가까울 수록 값이 커지지만 환경에 따라 크게 달라질 수 있다.

센서 노드에 업로드 된 프로그램의 삭제

2009-07-13T18:17:00.000-07:00

보통 센서 노드에 업로드 된 기존의 프로그램은 새로운 어플리케이션을 올림으로써 덮어쓰는 방식으로 사용한다. 이유는 귀찮기 때문이다. -.-
다음과 같은 방법을 사용해 보도록 하자.

--------------------------------------------------------------
센서 노드가 USB로 연결되었다는 가정하에
$>tos-bsl --telosb -c /dev/ttyUSB0 -r -e 명령으로 실행하면
MSP430 Bootstrap Loader Version: 1.39-telos-8
Use -h for help
Mass Erase...
Transmit default password...
Reset device...
--------------------------------------------------------------

끝.

리눅스에서 특정 파일 삭제

2009-07-12T18:15:00.000-07:00

swp 파일이나 tmp 파일이 남아있게 된 경우 다음과 같은 방법으로 날릴 수 있다.

ex) vim의 swp 파일 삭제
$>find . -name *.swp -exec rm -f {} \;

경로 설정시 주의...

use the Listen java program to record the output stream.

2009-07-06T00:54:00.000-07:00

Listen command on Terminal:

$ export MOTECOM=serial@/dev/ttyUSB0:platform name

$ java net.tinyos.tools.Listen > TestOutput.txt or
$ java net.tinyos.tools.Listen | TestOutput.txt

Beginning on the stargate

2009-06-28T19:58:00.000-07:00

I think there is a 2nd alternative to using java for sending andreceiving packets from the mote.
If you look at tinyos-1.x/tools/src/sf there are some C files that followthe serial framing protocol used by the motes to send TOS packets over theserial port.
I think this directory contains the implementation of theSerialForwarder is C.
I have only used the serialsource.c and seriallisten.c and compiled themtogether to produce a TinyOS packet dump of the serial port.
So do the following on your PC:

$ cd /tools/src/sf
$ gcc -o seriallisten serialsource.c seriallisten.c
$./seriallisten /dev/ttyUSB0 57600

is where you have installed tinyos (e.g /opt/tinyos-1.x).

- xbow -

moteiv boomerang 환경설정

2009-06-18T20:45:00.000-07:00

# tinyos_boomerang.sh : Prepare environment for Boomerang
# Place this file in /etc/profile.d/

export MOTEIV_DIR=/opt/tinyos-1.x/contrib/boomerang
export TOSMAKE_PATH=$MOTEIV_DIR/tools/make

# help build files in $TOSDIR/../tools/java/net/tinyos
export MIGFLAGS="-target=telosb -I$TOSDIR/lib/CC2420Radio"
export SURGE_PLATFORM=telos

for a in $MOTEIV_DIR/tools/java/jars/* $MOTEIV_DIR/tools/java
do
if [ -f /bin/cygwin1.dll ]; then
export CLASSPATH="`cygpath -w "$a"`;$CLASSPATH"
else
export CLASSPATH="$a:$CLASSPATH"
fi
done

windows에 T1 & T2 설치.

2009-06-17T23:41:00.000-07:00

windows에 t1과 t2를 설치, cygwin을 이용한 개발 환경을 구축하기 위해서는

1. Java SDK 설치
java 1.5 jdk -> http://java.sun.com/

2. cygwin 설치
http://www.cygwin.com/ or
http://www.tinyos.net/dist-1.2.0/tools/windows/cygwin-1.2a.tgz
setup - Install from Local Directory - Root Directory 설정 - Select Package All install로 모두 설정 - install

3. cygwin-x 설치
http://www.cygwin.com/setup.exe
setup - install from internet - directory 설정 - 다운로드 받을 임시 디렉토리 설정 - Use IE5 Settings - FTP site 설정 - X11 항목 install - install
설치 완료 후 startxwin.sh 를 실행하여 설치 확인

4. TI MSP430 Tools 설치
http://www.tinyos.net/dist-1.2.0/tools/windows/
설치 명령 : rpm -ivh --ignoreos --nodeps --force
-base-0.1
-python-tools-1.0-1
-binutils-2.16
-gcc-3.2.3
-libc

5. TinyOS Toolchain (nesC, tinyos-tools) 설치
http://www.tinyos.net/dist-1.2.0/tinyos/windows/
-nesc-1.2.8a-1
-tinyos-tools-1.2.3-1

6. Graphviz 설치
http://www.graphviz.org/

7. tinyos 1.x & 2.x & 2.x-contrib source tree 다운로드
$ cd /opt
$ cvs -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos login
$ cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co -P tinyos-1.x tinyos-2.x tinyos-2.x-contrib

8. 환경설정
$ vim ~/.bashrc
export TOSROOT=/opt/tinyos-2.x
export TOSDIR = $TOSROOT/tos
export CLASSPATH = `cygpath -w $TOSROOT/support/sdk/java/tinyos.jar`
export CLASSPATH = "$CLASSPATH;."
export MAKERULES = $TOSROOT/support/make/Makerules
export PATH = /opt/msp430/bin:$PATH
$ source ~/.bashrc

9. java tool 컴파일
$ tos-install-jni

10. 설치 후 검증
$ cd /opt/tinyos-1.x/tools/script
$ ./toscheck

컴파일 및 빌드 시 target name 변경

2009-06-02T22:51:00.000-07:00

* opt/tinyos-1.x/tools/make 폴더 내에 target name.target 파일 생성.
-> telosb 계열의 경우 telosb.target의 내용을 복사해서 사용한다.
변경할 내용은 다음과 같다.
-------------------------------------------
...
PLATFORM ?= target name
...
$(call TOSMake_include_platform, msp)
target name : $(BUILD_DEPS)
...
-------------------------------------------

* opt/tinyos-1.x/tos/platform 폴더 내에 해당 target device 폴더 생성.
-> telosb 계열의 플랫폼일 경우 telosb 폴더를 복사해서 사용한다.
상위 target name 과 같은 플랫폼 이름을 적용해야 한다.

OTA(Over The Air)

2009-05-23T09:55:00.000-07:00

Deluge는 대규모 센서 네트워크에서 센서 노드들의 무선 프로그래밍을 가능하게 한다. 컴파일 된 프로그램의 binary와 같은 data object를 네트워크내에 있는 센서 노드들에게 퍼뜨리는 방법으로 이를 보통 OTA(Over the Air) Programming or Reprogramming 이라고 한다. 센서 네트워크에서 네트워크를 이루고 있는 센서 노드의 갯수가 증가할 경우에, 센서 노드에 일일이 프로그램을 다운로드하는 것은 비효율적이다. 이 경우 Deluge 매카니즘을 사용하게 되면 매우 효과적이다.

Deluge 2.0

- Goals :
• robustness & useability가 강화된 network programming

- Features :
• Multihop 지원 : multihop 네트워크 안의 모든 노드에 무선으로 프로그램 적재
• Epidemic propagation : 모든 노드에 의한 연속적인 전파 전달로, 통신율이 낮은 노드에도 전파 전달이 되도록 기여함.
• Redundant data integrity checks : CRC계산으로, 모든 노드의 프로그램 이미지 무결성을 보장하도록 기여함.
• Store multiple program images : 프로그램 이미지를 여러 개 저장함으로써, 계속되는 다운로드 없이도, 프로그램을 빠르게 교환.
• Golden image : 최소한의 network programming을 지원하는 프로그램 이미지로 외부 flash의 안전한 위치에 저장된다. 복구에 필요한 코드 부분이 있다.
• Isolated bootloader : TinyOS 어플리케이션의 리셋 후에 실행을 보장하는 코드. bootloader는 마이크로컨트롤러 프로그래밍과 관련되어 있으며, 프로그래밍 에러시 Golden Image를 읽어서 복구한다.
• Rollback gesture : 노드 고장시, 리셋 스위치를 여러 번 누르면, Golden image로 전환되어 새로운 프로그램을 받아들일 수 있도록 준비됨.
• Small RAM foot print : 150byte 미만의 메모리 차지.

- Improvement :
• 프로그래밍 전에 이미지가 유효한가에 대한 이미지 검증
• 프로그래밍 실패시 자동으로 Golden Image로 rollbak
• 어플리케이션의 의한 Golden image의 수정을 방지
• 프로그램에 대한 다양한 정보(program name, compile time, host name ...)
• CRC를 포함한 metadata 데이터구조를 사용
• Deluge나 TOSBase node 연결시 자동으로 감지
• 불완전한 이미지 자동 재시작
• 동일한 이미지 자동 감지

- Compatible platform :
• Mica2, Mica2-doc, MicaZ, Telos Rev.A, Telos Rev.B, TmoteSky

- Deluge Testing :
•
• Formatting the Flash ; Flash 메모리의 FAT를 위한 formatting
1) tinyos-1.x/apps/TestDeluge의 FlashFormat 어플리케이션 install
2) reset후 자동으로 포맷 시작(Yellow On), Success종료(Green On), Fail종료(Red On)

• Installing Deluge ; 기본 Deluge 어플리케이션과 TOSBoot 인스톨
1) tinyos-1.x/apps/TestDeluge의 DelugeBasic 어플리케이션 install(must set node ID)

• Pinging the Node ; Deluge java tool chain으로 현재 노드의 Deluge확인
1) Deluge가 적용된 노드를 UART로 연결한다.(SerialForwarder 혹은 MOTECOM 환경변수 설정)
2) java net.tinyos.tools.Deluge --ping
3) result screen

• Installing the Golden Image ; Deluge를 지원하는 최소 기능을 포함한 TinyOS application
1) application compile
2) build/telosb/tos_image.xml 생성 확인
3) java net.tinyos.tools.Deluge -i -in=0 -ti=./build/telosb/tos_image.xml 명령으로 Golden Image 생성 및 업로드(Golden image는 특별한 어플리케이션으로 직접연결로만 다운로드 가능)
4) 다른 노드에도 1~3의 과정으로 Golden image 다운로드 할 것.

• preparing your code : deluge 사용을 위해 사용자 어플리케이션에 deluge적용
1) top level configuration에서 DelugeC Component 추가, Main과 DelugeC wiring

• injecting a New Program image
1) java net.tinyos.tools.Deluge -i -in=1 -ti=./build/telosb/tos_image.xml

• reprogramming with a New program image
1) java net.tinyos.tools.Deluge -r -in=1(1번 image가 프로그래밍되어 동작됨. (GroupID, NodeID 유지됨))

- Deluge command :
• Ping
# java net.tinyos.tools.Deluge --ping
• Inject
# java net.tinyos.tools.Deluge --inject --tos_image= --imgnum=
• Reboot
# java net.tinyos.tools.Deluge --reboot --imgnum=
• Erase
# java net.tinyos.tools.Deluge --erase --imgnum=
• Reset
# java net.tinyos.tools.Deluge --reset --imgnum=
• Dump(extract)
# java net.tinyos.tools.Deluge --dump --imgnum= --outfile=

T1에서 컴파일 에러 문제

2009-05-20T21:12:00.000-07:00

xubuntu 플랫폼에서 t1의 경우 nesc 컴파일러 1.3.0 버전을 사용하면 컴파일시 에러가 발생하는 경우가 생긴다. (대표적으로 DemoSensorC 컴포넌트 및 하위 인터페이스)

** version 확인은 다음과 같이...
#nescc --version

이를 해결하기 위해서는 nesc 컴파일러를 1.2.8a를 새로 설치하면 된다.
설치방법은 http://www.tinyos.net/dist-2.0.0/tinyos/linux 에서 해당 컴파일러를 찾아 다운로드 한 후, rpm 파일을 deb 파일로 변환하여 설치하도록 한다.

windows에 t1 설치 및 삭제

2009-05-20T08:12:00.000-07:00

* windows에 tinyos-1.x 설치하기.

1. http://www.tinyos.net/dist-1.1.0/tinyos/windows/ 에서 tinyos-1.1.0-1is.exe를 다운로드 받아 실행한다.

2. t1의 최신버전인 1.1.15로 업그레이드 하기 위해 마찬가지로 위 사이트에서 tinyos-1.1.15Dec2005cvs-1.cygwin.noarch.rpm을 cygwin이 설치된 하부 디렉토리내에 다운로드 한다.

3. cygwin을 실행하여 1.1.15 rpm 파일이 위치한 곳으로 이동하여 다음 명령을 통해 업그레이드 하면 끝.

$ rpm --force --ignoreos -Uvh tinyos-1.1.15Dec2005cvs-1.cygwin.noarch.rpm

4. 설치가 완료되면 rpm -qa 명령을 통해 설치된 내용을 확인한다.

** windows에서 tinyos-1.x 삭제하기.

설치된 tinyos를 삭제하기 위해서는 다음의 순서를 꼭 따라야한다. 아니면 이 후 재설치 시 설치가 되지 않는 문제가 생길 수 있다.

1. 바탕화면의 Cygwin 바로가기 삭제
2. 시작-프로그램-Cygwin 폴더 삭제
3. 제어판-프로그램 추가/삭제-TinyOS 삭제
4. C:\Program Files\UCB 삭제
5. 시작-실행-regedit 를 실행한 후 Software\Cygnus Solutions 를 찾아 모두 삭제

duty cycle

2009-05-17T17:54:00.000-07:00

듀티 사이클 (duty cycle)

송신 신호가 개폐되면서 한 주기를 이룰 때, 한 주기(= 전류가 흐른 시간 + 전류가 흐르지 않은 시간)에 대한 전류가 흐른 시간의 비를 듀티 사이클이라 하며, 또 전류가 흐르지 않은 시간에 대한 전류가 흐른 시간의 비를 듀티 비라고 한다.

TinyOS-2.x Overview

2009-05-15T07:55:00.000-07:00

1. Introduction
TinyOS 2.0 is a clean slate redesign and re-implementation of TinyOS. Its development was motivated by our belief that many aspects of 1.x strain to meet requirements and uses that were not foreseen when it was designed and implemented. The structure and interfaces 1.x defines have several fundamental limitations. While these limitations can be worked around, this practice has led to tightly coupled components, hard to find interactions, and a very steep learning curve for a newcomer to sensor network programming.
TinyOS 2.0 is not backwards compatible with 1.x: code written for the latter will not compile for the former. However, one important aspect of 2.0's design is to minimize the difficulty of upgrading code. Therefore, while porting a 1.x application to 2.0 will require some work, it should not be very much.
This document provides a high-level overview of 2.0 and describes some of the ways in which it departs from 1.x. It covers the basic TinyOS abstractions, such as hardware abstractions, communication, timers, the scheduler, booting and initialization. Further detail on each of these can be found in TEPs (TinyOS Enhancement Proposals), which document and describe these abstractions.

2. Platforms/Hardware Abstraction
Platforms exist in the tos/platforms subdirectory. In TinyOS 2.0, a platform is a collection of chips and some glue code that connects them together. For example, the mica2 platform is the CC1000 radio chip and the ATmega128 microcontroller, while the micaZ platform is the CC2420 radio and the ATmega128 microcontroller, and the Teloi platforms are the CC2420 radio and the MSP430 microcontroller. Chip code exists in tos/chips. A platform directory generally has a .platform file, which has options to pass to the nesC compiler. For example, the mica2 .platform file tells ncc to look in chips/cc1000 and chips/atm128 directories, as well as to use avr-gcc to compile a mote binary (Teloi platforms tell it to use msp430-gcc).
Hardware abstractions in TinyOS 2.0 generally follow a three-level abstaction heirarchy, called the HAA (Hardware Abstraction Architecture).
At the bottom of the HAA is the HPL (Hardware Presentation Layer). The HPL is a thin software layer on top of the raw hardware, presenting hardare such as IO pins or registers as nesC interfaces. The HPL generally has no state besides the hardware itself (it has no variables). HPL components usually have the prefix Hpl, followed by the name of the chip. For example, the HPL components of the CC1000 begin with HplCC1000.
The middle of the HAA is the HAL (Hardware Abstraction Layer). The HAL builds on top of the HPL and provides higher-level abstractions that are easier to use than the HPL but still provide the full functionality of the underlying hardware. The HAL components usually have a prefix of the chip name. For example, the HAL components of the CC1000 begin with CC1000.
The top of the HAA is the HIL (Hardware Independent Layer). The HIL builds on top of the HAL and provides abstractions that are hardware independent. This generalization means that the HIL usually does not provide all of the functionality that the HAL can. HIL components have no naming prefix, as they represent abstractions that applications can use and safely compile on multiple platforms. For example, the HIL component of the CC1000 on the mica2 is ActiveMessageC, representing a full active message communication layer.
The HAA is described in TEP 2: Hardware Abstraction Architecture[TEP2].
Currently (as of the 2.0 release in November 2006), TinyOS 2.0 supports the following platforms:

•eyesIFXv2
•intelmote2
•mica2
•mica2dot
•micaZ
•telosb
•tinynode
•btnode3

The btnode3 platform is not included in the RPM.

3. Scheduler
As with TinyOS 1.x, TinyOS 2.0 scheduler has a non-preemptive FIFO policy. However, tasks in 2.0 operate slightly differently than in 1.x.
In TinyOS 1.x, there is a shared task queue for all tasks, and a component can post a task multiple times. If the task queue is full, the post operation fails. Experience with networking stacks showed this to be problematic, as the task might signal completion of a split-phase operation: if the post fails, the component above might block forever, waiting for the completion event.
In TinyOS 2.x, every task has its own reserved slot in the task queue, and a task can only be posted once. A post fails if and only if the task has already been posted. If a component needs to post a task multiple times, it can set an internal state variable so that when the task executes, it reposts itself.
This slight change in semantics greatly simplifies a lot of component code. Rather than test to see if a task is posted already before posting it, a component can just post the task. Components do not have to try to recover from failed posts and retry. The cost is one byte of state per task. Even in large systems such as TinyDB, this cost is under one hundred bytes (in TinyDB is is approximately 50).
Applications can also replace the scheduler, if they wish. This allows programmers to try new scheduling policies, such as priority- or deadline-based. It is important to maintain non-preemptiveness, however, or the scheduler will break all nesC's static concurrency analysis. Details on the new scheduler and how to extend it can be found in TEP 106: Schedulers and Tasks[TEP106].

4. Booting/Initialization
TinyOS 2.0 has a different boot sequence than 1.x. The 1.x interface StdControl has been split into two interfaces: Init and StdControl. The latter only has two commands: start and stop. In TinyOS 1.x, wiring components to the boot sequence would cause them to be powered up and started at boot. That is no longer the case: the boot sequence only initializes components. When it has completed initializing the scheduler, hardware, and software, the boot sequence signals the Boot.booted event. The top-level application component handles this event and start services accordingly. Details on the new boot sequence can be found in TEP 107: TinyOS 2.x Boot Sequence[TEP107].

5. Virtualization
TinyOS 2.0 is written with nesC 1.2, which introduces the concept of a 'generic' or instantiable component. Generic modules allow TinyOS to have reusable data structures, such as bit vectors and queues, which simplify development. More importantly, generic configurations allow services to encapsulate complex wiring relationships for clients that need them.
In practice, this means that many basic TinyOS services are now virtualized. Rather than wire to a component with a parameterized interface (e.g., GenericComm or TimerC in 1.x), a program instantiates a service component that provides the needed interface. This service component does all of the wiring underneath (e.g., in the case of timers, to a unique) automatically, reducing wiring mistakes and simplifying use of the abstraction.

6. Timers
TinyOS 2.0 provides a much richer set of timer interfaces than 1.x. Experience has shown that timers are one of the most critical abstractions a mote OS can provide, and so 2.0 expands the fidelity and form that timers take. Depending on the hardware resources of a platform, a component can use 32KHz as well as millisecond granularity timers, and the timer system may provide one or two high-precision timers that fire asynchronously (they have the async keyword). Components can query their timers for how much time remainins before they fire, and can start timers in the future (e.g., 'start firing a timer at 1Hz starting 31ms from now'). TEP 102: Timers[TEP102] defines what HIL components a platform must provide in order to support standard TinyOS timers. Platforms are required to provide millisecond granularity timers, and can provide finer granularity timers (e.g., 32kHz) if needed.
Timers present a good example of virtualization in 2.0. In 1.x, a program instantiates a timer by wiring to TimerC:

components App, TimerC;
App.Timer -> TimerC.Timer[unique("Timer")];

In 2.0, a program instantiates a timer:
components App, new TimerMilliC();
App.Timer -> TimerMilliC;

7. Communication
In TinyOS 2.0, the message buffer type is message_t, and it is a buffer that is large enough to hold a packet from any of a node's communication interfaces. The structure itself is completely opaque: components cannot reference its fields. Instead, all buffer accesses go through interfaces. For example, to get the destination address of an AM packet named msg, a component calls AMPacket.destination(msg).
Send interfaces distinguish the addressing mode of communication abstractions. For example, active message communication has the AMSend interface, as sending a packet require an AM destination address. In contrast, broadcasting and collection tree abstractions have the address-free Send interface.
Active messages are the network HIL. A platform's ActiveMessageC component defines which network interface is the standard communication medium. For example, a mica2 defines the CC1000 active message layer as ActiveMessageC, while the TMote defines the CC2420 active message layer as ActiveMessageC.
There is no longer a TOS_UART_ADDRESS for active message communication. Instead, a component should wire to SerialActiveMessageC, which provides active message communication over the serial port.
Active message communication is virtualized through four generic components, which take the AM type as a parameter: AMSenderC, AMReceiverC, AMSnooperC, and AMSnoopingReceiverC. AMSenderC is virtualized in that the call to send() does not fail if some other component is sending (as it does with GenericComm in 1.x). Instead, it fails only if that particular AMSenderC already has a packet outstanding or if the radio is not in a sending state. Underneath, the active message system queues and sends these outstanding packets. This is different than the QueuedSendC approach of 1.x, in which there is an N-deep queue that is shared among all senders. With N AMSenderC components, there is an N-deep queue where each sender has a single reserved entry. This means that each AMSenderC receives 1/n of the available post-MAC transmission opportunities, where n is the number of AMSenderC components with outstanding packets. In the worst case, n is the number of components; even when every protocol and component that sends packets is trying to send a packet, each one will receive its fair share of transmission opportunities.
Further information on message_t can be found in TEP 111: message_t[TEP111], while further information on AM can be found in TEP 116: Packet Protocols[TEP116].
The current TinyOS release has a low-power stack for the CC1000 radio (mica2 platform) and an experimental low-power stack for the CC2420 radio (micaz, telosb, and intelmote2 platforms).

8. Sensors
In TinyOS 2.0, named sensor components comprise the HIL of a platform's sensors. TEP 114 describes a set of HIL data acquisition interfaces, such as Read, ReadStream, and Get, which sensors provide according to their acquisition capabilities.
If a component needs high-frequency or very accurate sampling, it must use the HAL, which gives it the full power of the underlying platform (highly accurate platform-independent sampling is not really feasible, due to the particulars of individual platforms). Read assumes that the request can tolerate some latencies (for example, it might schedule competing requests using a FIFO policy).
Details on the ADC subsystem can be found in TEP 101: Analog-to-Digital Converters[TEP101]; details on the organization of sensor boards can be found in TEP 109: Sensorboards[TEP109], and the details of the HIL sensor interfaces can be found in TEP 114: Source and Sink Independent Drivers[TEP114].

9. Error Codes
The standard TinyOS 1.x return code is result_t, whose value is either SUCCESS (a non-zero value) or FAIL (a zero value). While this makes conditionals on calls very easy to write (e.g., if (call A.b())), it does not allow the callee to distinguish causes of error to the caller. In TinyOS 2.0, result_t is replaced by error_t, whose values include SUCCESS, FAIL, EBUSY, and ECANCEL. Interface commands and events define which error codes they may return and why.
From the perspective of porting code, this is the most significant different in 2.0. Calls that were once:

if (call X.y()) {
busy = TRUE;
}

now have their meanings reversed. In 1.x, the busy statement will execute if the call succeeds, while in 2.0 it will execute if the call fails. This encourages a more portable, upgradable, and readable approach:

if (call X.y() == SUCCESS) {
busy = TRUE;
}

10. Arbitration
While basic abstractions, such as packet communication and timers, can be virtualized, experiences with 1.x showed that some cannot without either adding significant complexity or limiting the system. The most pressing example of this is a shared bus on a microcontroller. Many different systems -- sensors, storage, the radio -- might need to use the bus at the same time, so some way of arbitrating access is needed.
To support these kinds of abstractions, TinyOS 2.0 introduces the Resource interface, which components use to request and acquire shared resources, and arbiters, which provide a policy for arbitrating access between multiple clients. For some abstractions, the arbiter also provides a power management policy, as it can tell when the system is no longer needed and can be safely turned off.
TEP 108: Resource Arbitration[TEP108] describes the Resource interface and how arbiters work.

11. Power Management
Power management in 2.0 is divided into two parts: the power state of the microcontroller and the power state of devices. The former, discussed in TEP 112: Microcontroller Power Management[TEP112], is computed in a chip-specific manner by examining which devices and interrupt souces are active. The latter, discussed in TEP 115: Power Management of Non-Virtualised Devices{TEP115], is handled through resource abiters. Fully virtualized services have their own, individual power management policies.
TinyOS 2.0 provides low-power stacks for the CC1000 (mica2) and CC2420 (micaz, telosb, imote2) radios. Both use a low-power listening apporach, where transmitters send long preambles or repeatedly send packets and receivers wake up periodically to sense the channel to hear if there is a packet being transmitted. The low-power stack CC1000 is standard, while the CC2420 stack is experimental. That is, the default CC1000 stack (chips/cc1000) has low-power-listening, while the default CC2420 stack (chips/cc2420) does not. To use the low-power CC2420 stack, you must include chips/cc2420_lpl in your application Makefile.

12. Network Protocols
TinyOS 2.0 provides simple reference implementations of two of the most basic protocols used in mote networks: dissemination and collection. Dissemination reliably delivers small (fewer than 20 byte) data items to every node in a network, while collection builds a routing tree rooted at a sink node. Together, these two protocols enable a wide range of data collection applications. Collection has advanced significantly since the most recent beta release; experimental tests in multiple network conditions have seen very high (>98%) deliver rates as long as the network is not saturated.

13. Conclusion
TinyOS 2.0 represents the next step of TinyOS development. Building on user experiences over the past few years, it has taken the basic TinyOS architecture and pushed it forward in several directions, hopefully leading to simpler and easier application development. It is still under active development: future prereleases will include non-volatile storage, basic multihop protocols (collection routing, dissemination), and further power management abstractions.

xubuntu network 설정

2009-05-15T07:43:00.000-07:00

처음 xubuntu를 설치하게 되면 dhcp로 IP가 할당된다.
수동으로 고정 IP를 설정하기 위해서는

# vim /etc/networking/interfaces 파일의 내용을 다음과 같이 변경한다.

# iface eth0 inet dhcp 부분을 주석처리하고,
iface eth0 inet static
address 192.168.100.xxx
netmask 255.255.255.0
network 192.168.xxx.xxx
broadcast 192.168.xxx.xxx
gateway 192.168.xxx.xxx

위와 같이 설정이 끝나면 네트워킹을 재시작한다.
# sudo /etc/init.d/networking restart

변경된 IP 주소를 확인한다.
# ifconfig

xubuntu에 ssh 설치

2009-05-15T07:38:00.000-07:00

1. ssh 설치
# sudo apt-get install ssh

2. 재시작
# sudo /etc/init.d/ssh restart

3. 확인
# netstat -ntl

xubuntu에 samba 설치

2009-05-15T07:21:00.000-07:00

우분투에서 samba를 이용하여 파일공유가 가능하다.

1. 파일 공유를 위한 서버에서 다음과 같이 samba package를 설치한다.
# sudo apt-get install samba smbfs

2. 접근할 ID와 비밀번호를 설정.
# sudo smbpasswd -a ID

3. samba 설정
# sudo vim /etc/samba/smb.conf

# 기본적인 설정
[global]
# 워크 그룹
workgroup = WORKGROUP
encrypt passwords = yes
# 접근 아이피 범위
hosts allow = 192.168.
# 문자 인코딩 설정, 우분투는 utf-8을 기본적으로
unix charset=utf-8
dos charset=utf-8
#공유 디렉토리 이름
[MyDoc]
comment = My Documents
path = /공유할/디렉토리/위치
#접근 설정 여부
read only = no
browsable = yes
등등... 필요한 내용을 입력한다.

ex)
# access IP address
[global]
host allow = 192.168
# authentication
[authentication]
security = user
# shared forder
[tinyos]
comment = xubuntu
path = /share
public = yes
available = yes
writeable = yes
create make = 0777
directory mask = 0777
guest ok = no
browseable = yes

4. 설정이 완료되면 재시작한다.
# sudo /etc/init.d/samba restart

the END.

xubuntu에 APM 설치

2009-05-15T07:04:00.000-07:00

xubuntu에서 APM의 설치는 의외로 간단하다.

1. apache2 설치
# sudo apt-get install apache2

2. php5 설치
# sudo apt-get install php5

3. mysql 설치
# sudo apt-get install mysql-server mysql-client

mysql과 php의 연동을 위해 다음과 같이 설치한다.
# sudo apt-get install php5-mysql

이상으로 기본적인 설치과정은 완료된다.

이제 apache 웹서버를 재시작한다.
# sudo /etc/init.d/apache2 restart

마찬가지로 mysql 서버도 재시작한다.
# sudo /etc/init.d/mysql restart

이로써 APM 환경이 구축된다.

Delta Application...

2009-05-14T21:39:00.000-07:00

modified boomerang Delta application...
(voltage, humidity & temperature)
----------------------------------------
CommunicationsMoteiv’s communication system includes three main components: a Multihop mesh networkingprotocol, a network duty cycling protocol, and the recently proposed “Sensornet Protocol” (SP)abstraction for sending and receiving messages. All of these protocols are used in Moteiv’smesh networking application, Delta.

Multihop Networking
Moteiv’s on-demand ad-hoc networking utilizes spatial and temporal redundancy to reliabilitydeliver messages across a network to their destination. To use the Multihop library in anapplication, first include Multihop in your configuration:

component Multihop;

Then wire your application to the appropriate message handlers for your message type. Forexample, in your configuration:

AppM.Send -> MultiHop.Send[APP_ID];
APPM.Receive -> MultiHop.Receive[APP_ID];

Where APP_ID is a unique 8-bit identifier for your service or application defined in a header file.Please see the documentation for details of using the Send interface in Moteiv’s APIdocumentation available at /opt/moteiv/docs/nesdoc

Messages are submitted to the Multihop service and queued until there is an opportunity toroute the message towards the destination. After a message is successfully sent, an event(Send.sendDone()) is fired to your service notifying you that it is now safe to use themessage buffer for other purposes.

Low Power Operation
Moteiv’s software includes a synchronization protocol for low power wireless network. Thenetwork duty cycling approaches uses SP (described below) for establishing and maintaining aschedule whereby the entire network wakes up together and then returns to sleep.

Including Moteiv’s network duty cycling is as simple as adding a single parameter to thecompilation command. Simply add the lowpower keyword after the compilation platform. Forexample:

make tmote lowpower

Try the low power networking by using Delta, the mesh networking data collection application,with the lowpower option:

cd /opt/tinyos-1.x/contrib/boomerang/apps/Delta
make tmote lowpower

Be aware that bandwidth is very limited in low power mode (each node is only awake for a fewmilliseconds every two seconds). The initial synchronization of the network may require up to15 minutes to stabilize, but will reliably report data after the initial setup phase. Please bepatient!

Information about Moteiv’s network duty cycling is included in the API documentation for theNetSyncC and NetWakeC components. The source is at /opt/moteiv/tos/lib/netsync;however we strongly recommend that only the most advanced users consider modifying thiscode. Please note that Moteiv does not support any modifications to our source.

Sensornet Protocol (SP)
SP is a unifying link abstraction for running network protocols over a variety of link layer andphysical layer technologies without changing network protocol implementation. SP isimplemented by the SPC component.

SPC and its interfaces are described in detail in the following publication:A Unifying Link Abstraction for Wireless Sensor NetworksIn Proceedings of the Third ACM Conference on Embedded Networked Sensor Systems(SenSys), November 2-4, 2005.
http://www.polastre.com/papers/sensys05-sp.pdf

Messages are transmitted using the SPSend interface and message futures are handledthrough the SPSendNext interface. To send a message on a particular AM type, such as AMtype 5, wire your network protocol to SPSend[5]. The SP message pool will hold on to amessage and its corresponding packets until it may be sent over the channel.

Fields of each SP message (sp_message_t) should never be directly accessed. Instead, theycan be set using the parameters of the SPSend interface. Reading parameters should be donethrough the SPMessage interface.

Reception is on a per packet basis (not a per message basis like SPSend). Packets areimmediately dispatched to higher layer services based on AM type. SPReceive providesinformation about each packet, including a token that identifies which interface a messageoriginated.

The SP Neighbor Table is accessed through the SPNeighbor interface. Users must wire to theSP Neighbor Table with the parameter unique("SPNeighbor"). Each service has its ownidentity for controlling the insertions, removals, and changes of entries in the SP NeighborTable. See the SPNeighbor interface in the API documentation for more information.

Various utilities as part of SP's processing are available in the SPUtil interface. These utilitiesinclude link estimation functions and link post-arbitration time stamps.

- moteiv corp -

Power Characteristic

2009-05-14T18:57:00.000-07:00

Basic Sensor Node

* AA Size battery 2ea
* USB 전원 인가하여 사용 가능
* CC2420은 DC 2.1v ~ 3.6v 범위에서 동작
* MSP430F1611 MCU는 1.8v ~ 3.6v 범위에서 동작
* USB 연결로 programming시 최소 2.7v 전원이 필요
* PC의 USB 인터페이스로부터 받은 5v 전원을 Regulator를 이용하여 3v 로 전환

TinyOS-1.x and Boomerang

2009-05-07T00:53:00.000-07:00

TinyOS-1.x and Boomerang

These installation instructions will only work on Windows XP and XubuntOS. In particular, they will not work on Windows Vista, nor Mac OS. It is possible to install the tmote tools on any distribution of linux, but it is a bit more involved. XubuntOS makes your life a lot easier. The following is loosely based on http://www.5secondfuse.com/tinyos/oldInstall.html. I just added a few lines to the .bash_tinyos script to implement the boomerang function.

Installation

Windows XP

To install on XP, you need the Boomerang tmote tools CD, which you can get from me, or download from http://www.ccs.neu.edu/home/acassola/tmote-tools-2_0_4.zip.
To start, run the setup.msi file from within windows. The installer will set up Cygwin, Java5, TinyOS, and the boomerang/tmote-tools for you. To work, you will need to open a cygwin shell window. The installer made sure all the software and variables have been set.

XubuntOS

If you are using anything other than windows XP, you will need access to a trial version of VMWare workstation from http://www.vmware.com/, and download the XubuntOS virtual machine image at http://www.5secondfuse.com/tinyos/xubuntos-2.0-vm.tar.gz.
XubuntOS is a modified ubuntu installation that runs the XFCE window manager and has installed (almost) all the required java and TinyOS components for us.

Now follow these steps:

1. After unpacking the image, open it with vmware. Go to the VM->Settings Menu Option and under USB Controller check the box ``Automatically Connect USB Devices to this virtual machine. Click on Save.

2. Start the xubunTOS virtual machine. Once the machine is up, you can login with username xubuntos and password tinyos.

3. Go to Applications->System->Synaptic Package Manager. Click on the Reload Button. Click on the Search button and enter msp430 in the box and click search. Select the msp430-tinyos package, version 2.1-20080806 for installation, and accept the next dialog. Click on the apply button, and apply the next dialog, too.

4. Click on the terminal icon (next to the firefox icon). Inside the terminal run the following command:
wget -O .bash_tinyos http://www.ccs.neu.edu/home/acassola/bash_tinyos

5. Download the tinyos-tools zip file by running
wget http://www.ccs.neu.edu/home/acassola/tmote-tools-2_0_4.zip
in the same terminal as above

6. Download the moteiv tools package and install it. Change the owner of the installation directory:
wget http://www.ccs.neu.edu/home/acassola/tinyos-moteiv_2.0.4-2_all.deb
sudo dpkg --install *.deb
**Type the tinyos password**
sudo chown -R xubuntos /opt/moteiv

7. You are all set. Exit the terminal you were using, open the Qickstart guide inside the tools CD, read it, and start playing. Check out the tinyos tutorials available in the internet.

To interact with the motes, you need to use a terminal. Opening a new terminal after completing these instructions will give you one that has all its environment variables set to the right values and is ready to work.

- http://www.ccs.neu.deu/home/acassola/installtos/ -

Oscilloscope 어플리케이션 되짚어 보기.

2009-05-07T00:00:00.000-07:00

Oscilloscope 어플리케이션 예제에서는 센싱 데이터가 2바이트씩 10개의 값을 보내도록 구현되어 있다. OscopeMsg 패킷의 형식을 보면 버퍼 사이즈 즉, 샘플링 데이터를 10개 수집하도록 되어 있기 때문이다. 하나씩 뜯어보도록 하자.

Tinyos에서 기본적으로 사용되는 TOS_Msg를 살펴보면
(/opt/tinyos-1.x/tos/platform/telos/AM.h)

#define TOSH_DATA_LENGTH 28
typedef struct TOS_Msg{
uint8_t length;
uint8_t fcfhi;
uint8_t fcflo;
uint8_t dsn;
uint16_t destpan;
uint16_t addr;
uint8_t type;
uint8_t group;
uint8_t data[TOSH_DATA_LENGTH];
uint16_t strength;
uint8_t lqi;
bool crc;
bool ack;
uint16_t time;
} TOS_Msg;

여기서 데이터가 저장되는 페이로드 부분은 int8_t data[TOSH_DATA_LENGTH]; 부분으로 총 28바이트의 크기를 가진다.
그리고 Oscilloscope에서 사용되는 OscopeMsg의 경우 TOS_Msg의 이 페이로드 부분, 즉 28바이트 크기를 가지는 data부분에 실려서 전송되며 별도의 헤더를 가진다.

enum {
BUFFER_SIZE = 10
};
struct OscopeMsg {
uint16_t sourceMoteID;
uint16_t lastSampleNumber;
uint16_t channel;
uint16_t data[BUFFER_SIZE];
} OscopeMsg;

총 28byte의 페이로드 중 6바이트를 OscopeMsg의 헤더로 사용하고 BUFFER_SIZE 크기 만큼인 20byte를 2바이트씩 10개의 데이터로 채운다. 즉, OscopeMsg 형태의 패킷을 사용하면 2바이트짜리 데이터가 패킷당 10개씩 들어오는 것이다.
왜 2바이트짜리를 사용하는가. 그것은 센서 노드에서 10~12bits의 ADC를 사용하기 때문이다. 즉, ADC를 거쳐 아날로그에서 디지털로 변환된 데이터의 크기는 10~12bits이고 이를 저장하기 위해서는 2바이트가 필요한 것이다. ADC에서 데이터를 변환하여 결과값이 나왔을때 호출되는 함수를 보면 async event result_t ADC.dataReady(uint16_t data); 와 같은 형식을 취하는데 인수로 넘어오는 uint16_t data가 ADC의 결과가 된다. 이 값을 보내기 위해서 당연히 2바이트 짜리 변수를 사용해서 보내는 것이다.

[TIP]
OscopeC 컴포넌트는 /opt/tinyos-1.x/tos/lib/Oscope에 위치해 있으며, 이 컴포넌트를 이용하여 (OscopeM.nc, Oscope.h와 함께) Oscilloscope에서 발생한 센서 데이터들을 센서 타입별로 OscopeMsg 형태로 만들어 RF로 전송하는 기능을 가진 컴포넌트이다.
/opt/tinyos-1.x/apps에 있는 Oscilloscope 어플리케이션은 오직 하나의 센서에 대해서만 처리하기 때문에 앞에서와 같은 기능 분리가 필요 없으나, /contrib/moteiv/apps에 있는 Oscilloscope 어플리케이션은 여러 개의 센서들에 대해서 샘플링하고, 이를 각각 OscopeMsg로 만들어서 전달하여야 하므로 위와 같은 기능을 분리한 것이다. 물론 사용자 어플리케이션에서 모든 것을 처리할 수도 있겠지만, 같은 것의 반복을 parameterized 인터페이스를 통해 좀 더 간결하고 쉽게 해결하기 위해 OscopeC 컴포넌트를 사용한다.

Makelocal

2009-05-03T05:54:00.000-07:00

/opt/tinyos-1.x/tools/make/Makelocal 파일을 다음과 같이 설정하거나 또는, 해당 어플리케이션의 Makefile 내에 추가하면 컴파일 시 해당 내용이 적용된다.

#DEFAULT_LOCAL_GROUP = 0x7d
#PFLAGS += -DCC2420_DEF_CHANNEL = 26
#PFLAGS += -DDEFAULT_BAUDRATE = 57600
#PFLAGS += -DCC2420_DEF_RFPOWER = 31

또한, PFLAGS를 이용하여 경로 include 할 컴포넌트 및 라이브러리를 추가할 시, 다음과 같이 사용하면 된다.
#PFLAGS += -I$(TOSDIR)/../contrib/ucb/tos/lib/Oscope

참고로 크로스컴파일러 옵션의 -I는 include 폴더를 지정하는 것이며, -D는 define, 즉 컴파일전 정의를 해주는 것이다.

#PFLAGS += -v 옵션으로 해당 어플리케이션에서 사용하는 모든 파일을 컴파일 시간에 확인할 수 있다. 또한 컴파일 시 어플리케이션에의 참조 파일 목록을 텍스트 파일로 저장할 수도 있다.
# make telosb 2&>test.txt

Issue

2009-05-01T05:04:00.000-07:00

* Low Power Listening *

Arch Rock에서 CC2420 기반의 Low Power Listening을 성공적으로 구현, 2007년 초부터 TinyOS-2.x에 LPL 코드가 공개되었다.
저 전력 통신을 위해서는 주기적으로 CC2420을 sleep/wake 동작이 가능하도록 해야 한다.
MAC 계층 에서 Telosb의 저 전력은 현재 많이 사용하는 SurgeTelos등과 같은 공개된 코드에서는 active 상태로 동작한다. CC2420은 active 상태에서는 20mA 이상의 전류가 항상 소모되고 있다. CC2420은 보통 17mA ~ 20mA 정도의 전력을 소비하므로 항상 wake 되어 있는 일반적인 SurgeTelos 등과 같은 어플리케이션의 경우 저 전력으로 동작시킬 수 없다.
저 전력을 구현하기 위해서는 TinyOS-2.x 의 LPL을 이용해야 한다. (tutorial 참조)
결론은 TinyOS-1.x 에서는 CC2420의 저 전력이 불가능하고, TinyOS-2.x 에서는 LPL이 지원되므로 저 전력으로 구현이 가능하다. 이 LPL은 Deluge를 구현한 Jonathan Hui가 만들었다. 현재 6LowPAN에서 왕성한 활동을 하고 있다.
CC1000 계열에서는 소프트웨어에서 Preamble을 제어 할 수 있다. CC2420은 보내고자하는 데이터를 버퍼로 입력해주면, 하드웨어가 알아서 전송한다. 즉, CC1000과 같이 세밀한 제어가 불가능 하다. CC2420은 대부분의 기능을 하드웨어가 하기 때문에, 새로운 알고리즘을 적용한 프로토콜을 만들어내기가 거의 불가능하다. 따라서 대부분의 학계 연구결과들은 CC1000을 기반으로 발표된 내용이며, S-MAC, PRIME, Funelling MAC 등 CC2420은 제약이 많다. 저 전력으로 구현하기에는 CC1000이 성능이 좋다. 그 이유는 Preamble을 가변적으로 조절해서 LPL을 구현할 수 있기 때문이다. CC2420은 데이터 전송률이 높으며, MCU와 연결하여 통신을 하기에 매우 편리하다. CC1000과 다르게 대부분의 기능을 하드웨어가 담당한다. 또한, CC2420은 IEEE 표준 기반이지만 CC1000은 아니다. 현재 비즈니스를 하는 대부분의 회사들은 표준을 따라 가고 있다. Vertical market은 한계를 가지고 있기 때문이다.
B-MAC은 ZigBee용 MAC이 아니다. 기본적으로 B-MAC은 CC1000 칩을 위한 MAC 프로토콜로 Preamble 을 동적으로 줄이고 늘이고 해야하기 때문에, CC2420에서는 불가능 하다. 보통 Telos 에 사용된 MAC을 LPL(Low Power Listening)이 없는 MAC이라고 부른다. 그동안의 Sensys 컨퍼런스 논문들을 보면, 센서 네트워크에서의 MAC이 어떻게 발전 되어 왔는지를 볼 수 있다. 그중 저전력을 목표로 구현한 것들이 많다. CC2420 칩이 20mA 정도를 항상 소비한다고 보면, 얼마나 잘 Sleep 시켰다가, wake up 시키느냐가 중요하다고 볼 수 있다.

- tinyos korea -

TinyOS Installation for Moteiv's Tmote Sky

2009-04-25T05:09:00.000-07:00

TinyOS Installation for Moteiv's Tmote Sky

UPDATED: October 17, 2007
Shortcut: Now you could follow this install guide... Or you can download the LiveCD and make your life much easier. This guide is generic across Ubuntu/Kubuntu/Xubuntu and the CD is specifically for Xubuntu. It's really up to you. If you want it you can find it here or at a mirror. But I can tell you that the CD is great. Its what I use and everything works. You don't need to do anything. So by all means use it! It really is the fastest way to start working in wireless sensor networks.

If you just can't bring yourself to install over your Windows partition and rebooting into XubunTOS everytime you want to work on TinyOS is too much as well... Then you are in luck. Kevin Klues at Stanford has been nice enough to make a VMware image of XubunTOS which runs in VMware's free "Player" software. You can download the software here (User: xubuntos Passwd: tinyos). You can find a copy of the image here. Download it and and answer yes if it asks you to switch your floppy or CD-Rom.

I've updated the instructions to use Stanford's Ubuntu repository. These packages and instructions were specifically written for Fiesty Fawn (7.04) however with some simple path changes they should work (maybe/probably) for Edgy Eft or Breezy Badger

I referenced the following guides to install TinyOS:

http://moteiv.com/community/Tmote_Linux_install (Dead link)
http://www.comnets.uni-bremen.de/typo3site/index.php?id=48
http://www.tinyos.net/tinyos-2.x/doc/html/install-tinyos.html

I also stole heavily from Wade Simmons and his Toiler's version. Thanks Wade! Another big thank you to Leith Abdulla, the deb packager at Stanford. Leith has updated the Stanford msp430 toolchains to fix the previous problem where the TinyOS toolchain wouldn't compile all Boomerang apps.

This guide is specifically for getting Tmote Sky hardware from Moteiv to work. I don't have any other motes to test this against. That said this should generally work (I think) for other motes.

TinyOS 1.x: With every passing day I forget more and more about TinyOS 1.x. I don't use it and I don't recommend you use it unless you need a library/protocol/application that hasn't been ported. And even in that case, port it and move out of TinyOS 1.x. I only do a quick and dirty test of TinyOS 1.x and all you can be certain of is Blink and that the Java SDK works.

DISCLAIMER: This is how I got things working. I have seen many of the example applications working, TOSSIM, etc. But I haven't stressed tested anything. Your mileage may vary. Let me know if you find things working differently.

NOTE: Recently its come to my attention that a lot of people are using this guide. That's great. But please if you reference the guide in your own web pages include a link and don't just yank the content. Its just not cool.

Ubuntu Packages
In order to insure you have all the required packages, you'll need to add the universe and multiverse repositories for Fiesty. You'll also need to add Stanford's TinyOS repository.

First, as root, open the /etc/apt/sources.list file

Then add the universe, multiverse and Stanford repositories.

deb http://tinyos.stanford.edu/tinyos/dists/ubuntu edgy main
deb http://us.archive.ubuntu.com/ubuntu/ feisty main restricted
deb-src http://us.archive.ubuntu.com/ubuntu/ feisty main restricted
deb http://us.archive.ubuntu.com/ubuntu/ feisty-updates main restricted
deb-src http://us.archive.ubuntu.com/ubuntu/ feisty-updates main restricted
deb http://us.archive.ubuntu.com/ubuntu/ feisty universe
deb-src http://us.archive.ubuntu.com/ubuntu/ feisty universe
deb http://us.archive.ubuntu.com/ubuntu/ feisty multiverse
deb-src http://us.archive.ubuntu.com/ubuntu/ feisty multiverse
deb http://security.ubuntu.com/ubuntu feisty-security main restricted
deb-src http://security.ubuntu.com/ubuntu feisty-security main restricted
deb http://security.ubuntu.com/ubuntu feisty-security universe
deb-src http://security.ubuntu.com/ubuntu feisty-security universe
deb http://security.ubuntu.com/ubuntu feisty-security multiverse
deb-src http://security.ubuntu.com/ubuntu feisty-security multiverse
deb http://tinyos.stanford.edu/tinyos/dists/ubuntu feisty main

Now you just need to add the packages.

sudo apt-get install cvs subversion autoconf automake1.9 python-dev
sudo apt-get install g++ g++-3.4 gperf swig sun-java5-jdk graphviz alien fakeroot
sudo apt-get install tinyos-msp430 tinyos-avr

Environment Variables
This guide sets up your development environment so you can use TinyOS 1.x, TinyOS 2.x, and Boomerang. To make life easy you can download this file here and save it to your home directory. You'll need to add a line to your .bashrc to source this file on login. If you use a different shell it would be fairly trivial to change over.

# Add this to your .bashrc
if [ -f ~/.bash_tinyos ]; then
. ~/.bash_tinyos
fi

This will allow you to switch between environments on fly.

metcalfc@TinyLaptop:~$ tos1
Setting up for TinyOS 1.x
... Do TinyOS 1.x work ...
metcalfc@TinyLaptop:~$ tos2
Setting up for TinyOS 2.x ...
... Do TinyOS 2.x work
metcalfc@TinyLaptop:~$ boomerang
Setting up for TinyOS 1.x with Boomerang
... Do TinyOS Boomerang work ...

Install TinyOS 1.x
cvs -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos login
cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co tinyos-1.x
sudo mv tinyos-1.x /opt

Install Boomerang
For the Moteiv specific Boomerang installation you'll need to get the files from... Someone who already has them. Moteiv is now Sentilla and they aren't supporting Boomerang.

mkdir tmote
cp tmote-tools-2_0_4.zip tmote
cd tmote
unzip tmote-tools-2_0_4.zip
cd common/rpms
fakeroot alien -d tinyos-moteiv-2.0.4-1.cygwin.noarch.rpm
sudo dpkg --install *.deb
cd ~
rm -rf tmote
sudo chown -R $USER /opt/moteiv

Optional: Install TinyOS from CVS
Most of the time I'm using TinyOS 2.x so I decided to use the bleeding edge from cvs. You can put it anywhere. I've chosen my home directory. You'll still have the official release in /opt. You'll also need to update your .bash_tinyos to reflect where you put it.

cvs -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos login
cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co tinyos-2.x
cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co tinyos-2.x-contrib

Java Serial Communications for TinyOS 1.x
You'll need to install TOSComm in order for your TinyOS 1.x Java toolchain to work. Yes, the TinyOS-tools package from TinyOS 2.x does this but it doesn't work for 1.x. And yes the two can coexist in your $JDKROOT.
The installer detects the wrong location to install the files to because of the alternatives setup.

Edit the JAVADIR rule in the $TOSROOT/beta/TOSComm/comm/Makefile with: JAVADIR=/usr/lib/jvm/java-1.5.0-sun

Now install it. We'll alias g++ to the correct version so we don't have to edit anymore makefiles.
alias g++=g++-3.4; cd $TOSROOT/beta/TOSComm/comm; sudo make install

The End

- 5secondfuse -

TinyOS 1 & 2 Installation on xubuntu 8.04 (hardy-heron) alternate

2009-04-24T02:05:00.000-07:00

1. download - xubuntu 8.04 (hardy-heron) PC(Inel x86) alternate install CD alternate.
www.xubuntu.com/get

2. excute vmware.

3. installation xubuntu.

4. Add Stanford's TinyOS repository.
#vim /etc/apt/sources.list file
deb http://tinyos.stanford.edu/tinyos/dists/ubuntu hardy main

update repository.
#sudo apt-get update

4. Add the packages.
#sudo apt-get install cvs subversion autoconf automake1.9 python-dev
#sudo apt-get install g++ g++-3.4 gperf swig sun-java5-jdk graphviz alien fakeroot
#sudo apt-get install msp430-tinyos avr-tinyos
#sudo apt-get install tinyos-tools (include all files)

5. Environment Variables
#vim /etc/profile.d/tinyos.sh
----------------------------------------------------------------------
#Java
export JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun
export JDKROOT=$JAVA_HOME
export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH
export CLASSPATH=$CLASSPATH:.

#Java can find libtoscomm.so and libgetenv.so
export LD_LIBRARY_PATH=$JDKROOT/jre/lib/i386

#Conditional environmental setup for TinyOS-1.x
export TOSROOT=/opt/tinyos-1.x
export TOSDIR=$TOSROOT/tos
export MAKERULES=$TOSROOT/tools/make/Makerules
export CLASSPATH=$CLASSPATH:$TOSROOT/tools/java

# Finally set the path for the MSPGCCROOT
export MSPGCCROOT=/usr/msp430
export PATH="$MSPGCCROOT/bin:$PATH"
---------------------------------------------------------------------------

6. Install TinyOS 1.x
cvs -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos login
cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co tinyos-1.x
# sudo mv tinyos-1.x /opt

7. Install TinyOS 2.x
cvs -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos login
cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co tinyos-2.x
cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co tinyos-2.x-contrib
# sudo mv tinyos-2.x /opt
# sudo mv tinyos-2.x-contrib /opt

8. Java Serial Communications for TinyOS 1.x
$TOSROOT/beta/TOSComm/comm/Makefile with:
JAVADIR=/usr/lib/jvm/java-1.5.0-sun
Now install it.
#alias g++=g++-3.4; cd $TOSROOT/beta/TOSComm/comm; sudo make install

or,,

RXTXComm install...
download site http://.www.rxtx.org/

$JAVA_HOME/jre/lib/i386/
librxtxParallel.so & librxtxSerial.so file

$JAVA_HOME/jre/lib/ext/
RXTXComm.jar file

tinyos java application source file modify...
import javax.comm.*; -> import gnu.io.*;

ubuntu 환경에서 rpm 파일을 deb 파일로 변환 설치

2009-04-24T01:07:00.000-07:00

우분투에서는 rpm파일을 rpm으로 설치하지 않고 이를 우분투용 패키지 설치파일인 deb로 변환 한 다음 설치해야 한다.
이 변환프로그램이 바로 alien인데 apt-get으로 패키지를 설치 할 수 있다.

# sudo apt-get install alien

alien이 설치되었다면 rpm을 deb로 변환해 주어야한다.

# sudo alien -c rpmfilename.rpm

변환과정이 끝나면 debfilename.deb파일이 생성된 것을 볼 수 있다.

이제 deb파일을 다음과 같이 설치한다.

# sudo dpkg -i rpmfilename.deb

vmware에서 xubuntu 사용 시 휠 마우스 문제

2009-04-19T21:04:00.000-07:00

/etc/X11/xorg.conf 파일을 다음과 같이 수정한다.

----------------------------------------
Section "InputDevice"
Identifier "Configured Mouse"
Driver "vmmouse"
Option "CorePointer"
Option "Device" "/dev/input/mice"
Option "Protocol" "ExplorerPS/2"
Option "ZAxisMapping" "4 5"
Option "Emulate3Buttons" "true"
EndSection
----------------------------------------

fedora 10에 이클립스 설치 후 nescdt plugin 추가.

2009-04-07T02:31:00.000-07:00

nescdt eclipse plugin 설치는 정말 간단하다.
다음의 링크에서 nescdt plugin을 다운로드 받아 eclipse가 설치된 폴더의 plugin 폴더에 삽입하면 끝.

http://docs.tinyos.net/index.php/NESCDT-_An_editor_for_nesC_in_Eclipse

Fedora 10에 eclipse 설치 및 환경설정

2009-04-03T19:19:00.000-07:00

1. eclipse를 다운로드 받는다. eclipse는 ganymede 3.4.2 classic 이다.
www.eclipse.org/ganymede

2. 사용자 계정(root 계정이 아닌)의 localhost 에 압축을 푼다.
$> tar -xvf

3. 압축을 풀고 실행을 하면 에러메시지가 뜨면서 동작하지 않는다. -.-
이를 해결하기 위해 eclipse 폴더에 있는 eclipse.ini 파일에 다음의 내용을 추가하고 재실행 한다.

.............................................
org.eclipse.platform
--launcher.XXMaxPermSize
256m
-vm
/opt/ibm/java2-i386-50/bin
-vmargs
.............................................

이제 이클립스가 정상적으로 동작할 것이다.

Fedora10 환경에서 TinyOS-1.x 와 TinyOS-2.x 사용하기.

2009-04-01T09:22:00.000-07:00

먼저 앞에서 다룬 내용을 참고하여 TinyOS-1.x를 설치하고, 다음 페이지를 참고하여 TinyOS-2.x 를 설치한다.

http://docs.tinyos.net/index.php/Installing_TinyOS_2.1#One-step_Install_with_a_live_CD

TinySO-2.x 를 다운로드 후 설치한다.
$>rpm -ivh --nodeps rpmname

그럼 /opt 폴더 아래 1.x와 2.x가 존재한다.
따로 설치가 되었지만 각각 사용하는 툴 및 컴파일러 등등은 같이 사용하는 것이므로 최신버전을 설치하는것이 좋다.

설치가 끝나면 환경설정을 해야한다.
상세 내용은 env.scripts 참조...

tinyos-1.x & tinyos-2.x env.scripts

2009-03-30T23:32:00.000-07:00

> TinyOS-1.x < /opt/env.scripts/env.opt.tinyos-1.x

unset CLASSPATH

export TOSROOT=/opt/tinyos-1.x
export TOSDIR=$TOSROOT/tos
export CLASSPATH=$TOSROOT/tools/java
export MAKERULES=$TOSROOT/tools/make/Makerules

echo "--------------------------------"
echo "Currently, TinyOS-1.x env."
eche "--------------------------------"
echo "TOSROOT="$TOSROOT
echo "TOSDIR="$TOSDIR
echo "MAKERULES="$MAKERULES
echo "--------------------------------"

export JAVA_HOME=/opt/ibm/java2-i386-50
export JDKROOT=$JAVA_HOME
export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH
export CLASSPATH=$CLASSPATH:.

export MSPGCCROOT=/opt/msp430
export PATH=$MSPGCCROOT/bin:$PATH

> TinyOS-2.x < /opt/env.scripts/env.opt.tinyos-2.x

unset CLASSPATH

export TOSROOT=/opt/tinyos-2.x
export TOSDIR=$TOSROOT/tos
export CLASSPATH=$TOSROOT/support/sdk/java/tinyos.jar:.
export MAKERULES=$TOSROOT/support/make/Makerules

echo "--------------------------------"
echo "Currently, TinyOS-2.x env."
echo "--------------------------------"
echo "TOSROOT="$TOSROOT
echo "TOSDIR="$TOSDIR
echo "MAKERULES="$MAKERULES
echo "--------------------------------"

export JAVA_HOME=/opt/ibm/java2-i386-50
export JDKROOT=$JAVA_HOME
export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH
export CLASSPATH=$CLASSPATH:.

export MSPGCCROOT=/opt/msp430
export PATH=$MSPGCCROOT/bin:$PATH

command :
source /opt/env.scripts/env.opt.tinyos-1.x --> 1.x env.
source /opt/env.scripts/env.opt.tinyos-2.x --> 2.x env.

- tinyos korea -

Windows에서 Eclipse를 이용한 TinyOS 개발 환경 구축

2009-03-30T09:05:00.000-07:00

1. TinyOS-1.x는 Eclipse 3.1.2 ver.에서 정상적으로 동작하므로 아래에서 다운로드 한다.
http://archive.eclipse.org/eclipse/downloads/drops/R-3.1.2-200601181600/index.php

2. 받은 파일의 압축을 적당히 원하는 곳에 풀면 끝.

3. TinyOS Plugin for Eclipse 설치를 위해 다음 사이트에서 TinyOS-UpdateSige1-1.zip 파일을 다운로드 받는다.
http://dcg.ethz.ch/~rschuler/OLD/installation.htm
다운로드가 완료되면 압축을 풀고 이클립스를 실행한다.

이클립스 실행 후
Help > Software Updates > Find and Insatall 선택
Search for new features to install 선택
New Local Site 클릭 후 다운로드 받은 TinyOS-UpdateSite1-1 파일 선택 후 확인
Update site가 등록되면 해당 Plugin 선택 후 Finish

4. 다운로드 받은 TinyOS-UpdateSite1-1 파일로 부터 검색 결과가 생성되면, Plugin 항목 중 suit 항목만 선택한다.
I accept the term in the license agreement 선택
Optional Features 창에서 TinyOS Wrapper Environment 1.0.5 항목만 선택
Plugin을 다운로드 받고, Install 을 통해 설치한다.

5. Eclipse restart
Window > Preference 선택
TinyOS 가 실제 설치된 경로 설정 후 확인

이로써 Eclipse를 이용한 TinyOS 개발환경이 구축된다.

TinyOS-1.x Installation on Linux(Fedora 10)

2009-03-28T22:18:00.000-07:00

콘솔(터미널)을 열어 root 권한으로 진행...

1. IBM Java sdk, javacomm 다운로드 받는다.
http://www.ibm.com/developerworks/java/jdk/linux/download.html 에서 아래 두 개의 rpm파일을 다운로드 받는다.
다운로드 받기 위해서 등록은 필수 -.-
IBM Java를 사용하는 이유는 설치가 쉬워서?? SUN Java는 설치가 어렵다는데... -.-

ibm-java2-i386-sdk-5.0-9.0.i386.rpm
ibm-java2-i386-javacomm-5.0-9.0.i386.rpm

파일을 다운로드 받았으면 설치를 한다.

$>yum localinstall --nogpgcheck ibm-java2-i386-jre-5.0-9.0.i386.rpm
$>yum localinstall --nogpgcheck ibm-java2-i386-sdk-5.0-9.0.i386.rpm
$>yum localinstall --nogpgcheck ibm-java2-i386-javacomm-5.0-9.0.i386.rpm

설치가 끝나면 /opt/ibm/java2-i386-50에 설치된다.
vi /root/.bashrc 파일을 열어 아래와 같은 내용의 Java path 및 환경변수를 추가하고 저장한다.

#JAVA
export JAVA_HOME=/opt/ibm/java2-i386-50
export JDKROOT=$JAVA_HOME
export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH
export CLASSPATH=.:$CLASSPATH

2. TinyOS linux tools 를 다운로드 및 설치한다.
http://www.tinyos.net/dist-1.1.0/tools/linux 와 http://www.tinyos.net/dist-1.2.0/tools/linux 에서 아래 파일들을 다운로드 받는다.

avarice-2.0.20030825cvs-1.i386.rpm
avr-binutils-2.13.2.1-1.i386.rpm
avr-gcc-3.3tinyos-1.i386.rpm
avr-insight-pre6.0cvs.tinyos-1.3.i386.rpm(rpm -ivh --replacefiles 명령으로 설치)
avr-libc-20030512cvs-1.i386.rpm
make-3.80tinyos-1.i386.rpm (기존에 파일이 없다고 나오는 경우 yum install make로 설치)
graphviz-1.10-1.i386.rpm ( graphviz tool의 경우 compile error를 발생시키므로 yum install graphviz로 설치)
msp430tools-base-0.1-20050607.i386.rpm
msp430tools-binutils-2.16-20050607.i386.rpm
msp430tools-gcc-3.2.3-20050607.i386.rpm
msp430tools-gdb-6.0-20050609.i386.rpm (설치시 에러가 나므로 일단 패스 -.-.)
msp430tools-gdb-proxy-6.0-20050609.i386.rpm (마찬가지로 패스 -.-.)
msp430tools-libc-20050308cvs-20050608.i386.rpm
msp430tools-jtag-lib-20031101cvs-20050610.i386.rpm
msp430tools-python-tools-1.0-1.noarch.rpm
nesc-1.2.8a-1.i386.rpm
tinyos-tools-1.2.3-1.i386.rpm
tinyos-1.1.15Dec2005cvs-1.noarch.rpm

다음과 같이 설치한다.

$>yum install gcc-c++
$>yum install make
$>yum localinstall --nogpgcheck avarice-2.4-1.i386.rpm
$>yum localinstall --nogpgcheck avr-binutils-2.15tinyos-3.i386.rpm
$>yum localinstall --nogpgcheck avr-gcc-3.4.3-1.i386.rpm
$>yum localinstall --nogpgcheck avr-libc-1.2.3-1.i386.rpm
$>rpm -ivh --replacefiles avr-insight-6.3-1.i386.rpm
$>yum install graphviz
$>yum localinstall --nogpgcheck nesc-1.2.8a-1.i386.rpm
$>yum localinstall --nogpgcheck tinyos-tools-1.2.3-1.i386.rpm
$>yum localinstall --nogpgcheck msp430tools-base-0.1-20050607.i386.rpm
$>yum localinstall --nogpgcheck msp430tools-binutils-2.16-20050607.i386.rpm
$>yum localinstall --nogpgcheck msp430tools-gcc-3.2.3-20050607.i386.rpm
$>yum localinstall --nogpgcheck msp430tools-libc-20050308cvs-20050608.i386.rpm
$>yum localinstall --nogpgcheck msp430tools-jtag-lib-20031101cvs-20050610.i386.rpm
$>yum localinstall --nogpgcheck msp430tools-python-tools-1.0-1.noarch.rpm
$>yum localinstall --nogpgcheck tinyos-1.1.15Dec2005cvs-1.noarch.rpm
CVS repository로부터 TinyOS source를 다운로드 받아 복사해도 되지만 이 부분은 아직 해보지 않아서 검증되지 않았지만 다음과 같이 source를 받아오면 된다.
이 때, 반드시 해당 디렉토리로 이동 후 명령 실행해야 한다.(opt/tinyos-1.x의 경로에 설치할 경우, /opt 폴더에서 실행)

$>cvs -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos login(passware를 물어보면 엔터를 친다.)
$>cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co -r tos-1-1-14-candidate tinyos-1.x
또는, cvs -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co tinyos-1.x(설치시간은 대략 30분 남짓 걸린다.)

만약 cvs 가 실행이 안 될 경우, cvs 설치한다.

$>yum install cvs
설치가 끝나면 vi /root/.bashrc 파일을 열어 아래와 같은 내용의 환경변수를 추가한다.

#MSPGCC
export MSPGCCROOT=/opt/msp430
export PATH=$MSPGCCROOT/bin:$PATH

#TinyOS
export TOSROOT=/opt/tinyos-1.x
export TOSDIR=$TOSROOT/tos
export CLASSPATH=$TOSROOT/tools/java:$CLASSPATH
export MAKERULES=$TOSROOT/tools/make/Makerules

3. 아래 내용중에 vi /root/.bashrc 파일을 열어 빠진 내용이 없는지 확인한다.

#Java
export JAVA_HOME=/opt/ibm/java2-i386-50
export JDKROOT=$JAVA_HOME
export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH
export CLASSPATH=$CLASSPATH:.

#MSPGCC
export MSPGCCROOT=/opt/msp430
export PATH=$MSPGCCROOT/bin:$PATH
#TinyOS
export TOSROOT=/opt/tinyos-1.x
export TOSDIR=$TOSROOT/tos
export CLASSPATH=$TOSROOT/tools/java:$CLASSPATH
export MAKERULES=$TOSROOT/tools/make/Makerules

이로써 fedora 10 환경에서 TinyOS를 사용할 수 있게 된다.
시스템을 재부팅을 하고, 마지막으로 테스트를 한다.

Blink 디렉토리로 이동~~

$>cd /opt/tinyos-1.x/apps/Blink
$>make install telosb
...
...
...
rm -f build/telosb/main.exe.out build/telosb/main.ihex.out

성공이다... :-)

*TIP
java tools 가 실행되지 않을 경우...
/opt/tinyos-1.x/tools/java 로 이동하여 컴파일...
$>make
해당 툴의 class 파일이 생성되면 사용가능하게 된다.

USB serial Comm. 을 위해 다음과 같이 수정한다.
$>vi /opt/ibm/java2-i386-50/jre/lib/javax.comm.properties의 내용 중

/dev/ttyS=PORT_SERIAL >> /dev/ttyUSB=PORT_SERIAL 로 변경 후 적용하면 끝.