WizFi310 is registered as a component of mbed.

The components of mbed are classified into categories such as Actuators, Communication, Display, Expansion Boards, Input, IoT & Web Service, Sensors, Storage.
https://os.mbed.com/components/

The products registered as mbed's components can easily be used to develop components easily using ARM's MCU and reusable libraries on mbed OS. 

The mbed registration page for WizFi310 is shown below. 
https://os.mbed.com/components/WizFi310-EVB/ 

Looking at WizFi310's headers in mbed, you can see various example code. 


https://os.mbed.com/teams/WIZnet/code/WizFi310_TCP_Echo_Server_Example/ 

https://os.mbed.com/teams/WIZnet/code/WizFi310_STATION_HelloWorld/ 

https://os.mbed.com/teams/WIZnet/code/WizFi310_OpenWeatherMap/ 

https://os.mbed.com/users/jehoon/code/KT_IoTMakers_WizFi310_Example/ 

https://os.mbed.com/users/jehoon/code/WiFiTracker/

In the example above, you can see that there is an indication of OS2 next to the title. 

This indication refers to an example running on mbed OS version 2. 
Currently, mbed OS is released up to version 5. 
https://os.mbed.com/blog/entry/Introducing-mbed-OS-5/ 

Therefore, it is difficult to refer to the above examples in order to use WizFi310 in the latest mbed OS 5. 


The driver code for WizFi310 running under mbed OS 5 is distributed through github below, and if mbed OS 5 is used in the mbed online compiler, it is compiled using the latest github code below. 
https://github.com/ARMmbed/wizfi310-driver 

The driver code included in mbed OS 5 can be easily ported for reusability even if you use the source code of other Communication Components. 
Using the above WizFi310 driver, the following items are linked to the Arm pelion Cloud. 

https://github.com/wpgnss/mbed-cloud-client-example

WizFi310을 mbed의 component로 등록 되어 있다.

mbed의 component는 여러 종류의 카테고리로 분류 되어 있다.

https://os.mbed.com/components/ 

- Actuators

- Communication

- Display

- Expansion Boards

- Input

- IoT&Web Service

- Sensors, Storage 


mbed의 component로 등록되어 있는 제품들은 Arm의 MCU와 mbed OS 상에서 재사용 가능한 라이브러리들을 활용해 쉽게 component를 쉽게 사용하여 개발할 수 있도록 도와준다. 

WizFi310의 mbed 등록 페이지는 아래와 같다.

https://os.mbed.com/components/WizFi310-EVB/ 

mbed에서 WizFi310의 얘제들을 검색해보면 다양한 예제 코드들을 확인할 수 있다.

https://os.mbed.com/teams/WIZnet/code/WizFi310_TCP_Echo_Server_Example/ 

https://os.mbed.com/teams/WIZnet/code/WizFi310_STATION_HelloWorld/

https://os.mbed.com/teams/WIZnet/code/WizFi310_OpenWeatherMap/

https://os.mbed.com/users/jehoon/code/KT_IoTMakers_WizFi310_Example/

https://os.mbed.com/users/jehoon/code/WiFiTracker/

위 예제들을 보면, 타이틀 옆에 OS2라는 표시가 있는 것을 확인할 수 있다. 

이 표시는 mbed OS version 2에서 동작하는 예제를 의미한다. 
현재 mbed OS는 version 5까지 릴리즈 되어 있다.  
https://os.mbed.com/blog/entry/Introducing-mbed-OS-5/ 

그렇기 때문에 최신 mbed OS 5에서 WizFi310을 사용하기 위해서는 위 예제들을 참고하기 어려운 점이 있다. 


mbed OS 5에서 동작하는 WizFi310의 드라이버 코드는 아래 github를 통해 배포되고 있으며, mbed online compiler에서 mbed OS 5를 사용할 경우 아래 github의 최신 코드를 사용하여 compile된다 
https://github.com/ARMmbed/wizfi310-driver

mbed OS 5에 포함된 드라이버 코드는 다른 Communication Components의 소스코드를 사용하더라도 재사용이 가능하기 때문에 쉽게 포팅해서 사용할 수 있다. 
위 WizFi310드라이버를 사용해 Arm pelion Cloud에 연동하는 얘제는 아래와 같다. 

https://github.com/wpgnss/mbed-cloud-client-example

LPWAN(Low Power Wide Area Network), 즉 적은 전력으로 긴 거리를 통신하는 기술이다. LPWAN은 통신빈도가 적고, 소량의 데이터를 사용하는 Metering, Tracking 등의 응용에 적합한대, LoRa와 NB-IoT가 바라보고 있는 응용 분야갸 같기 때문에 전혀 다른 기반기술임에도 많은 비교가 되고 있다.

이번 포스팅에서는 LoRa의 단점 중 하나라고 지적되는 LoRa의 보안 이슈를 SKT의 LoRa에 대해서 적어보려고 한다.(Public LoRa와 차이점이 있음.)

1. LoRa Device - Network Server

LoRa Device와 Gateway 사이는 비면허 대역이고 Broadcast로 통신하는 LoRa 특성상 보안 이슈가 발생할 수 있다.

일단 LoRaWAN 프로토콜 자체에서  AES-128 Encryption으로 Network Session Key를 관리한다. Public LoRa는 아래 그림에서 Pseudo App Key Join 단계만 수행하게 된다.

SKT LoRa는 Pseudo Join 단계를 통해 암호화된 Real App Key를 생성하게 되고, 이 Real App Key를 사용해 Real Join을 하도록 설계되어 있다. 다시말해 서로 다른 키를 이용해 AES-128로 2회 encryption 하는 것이다.

2단계의 Join 과정을 통해 Join Key가 외부로 유출되는 것을 원천 차단하고 있고, SKT에서 인증받지 않은 단말은 SKT LoRa Network에 접속할 수 없게 된다.

또한, LoRa는 IP 기반이 아닌 EUI64 기반의 ID 체계를 사용하기 때문에 DDOS, 스미싱, 스캐니닝, 바이러스 등 IP 기반의 공격에 안전하다.

2. ThingPlug - App Server

ThingPlug와 App/Web Server 사이에서는 MQTT/HTTP 기반에 oneM2M 프로토콜을 사용한다.

1) TCP Layer 보안

 MQTT와 HTTP는 TCP/IP Layer 기반에서 제공되는 SSL encryption도 지원하고 있다.

2) oneM2M Layer 보안

ThingPlug에서 REST API를 사용해 데이터를를 조회하거나, 디바이스를 조회하기 위해서는 사용자 인증키가 필요하다.

이 사용자 인증키는 SKT에서 발급해 주는 키로 타인의 접근을 방지는 역할을 하게 된다.

3) MQTT Layer 보안

MQTT를 사용하는 경우에도 oneM2M 프로토콜을 사용하기 때문에 사용자 인증키 보안을 사용한다.

추가로 경우 MQTT 접속시에 client ID, username, password를 적용하여 타인의 접속 자체를 차단하고 있다.

지난 겨울에 mosfet을 수리하고 얼마 지나지 않아 또 다시 고장이 났다.

증상

• 정상 동작하다가 방지턱 등 서스펜션에 충격이 가해지면 레드링이 뜨면서 멈추는 현상

추측

• 위 증상이 충격이 가해졌을 때 발생하는 것으로 보아 센서나 모터와 연결된 부분이 단선된 것으로 판단

진행상황

• 컨트롤러 내부의 메인 보드(배터리 연결 단자 아래쪽)에서 모터(앞 바퀴) 사이에 hall 센서 연결된 것으로 추정되는 선 중 하나 단선 확인
• 진행중.. 완료
• 분해하는데 참고한 영상  http://1byte.tistory.com/34
• 결론을 먼저 말하면, 수리 장비가 갖춰져 있지 않다면 그냥 수리를 맞기거나 컨트롤러를 구매해서 교체하는게 좋을 것 같다.
• 이 문제로 2번 수리 도전 했음
• 첫번째는 단선된 선을 이어 붙이기만 해보았고, 두번째로 커넥터를 통째로 바꿨음.
• 커넥터 교체를 위해서 구매한 커넥터 http://1byte.tistory.com/35

분해

1. 위 영상을 참고하면서 컨트롤러와 앞바퀴 등을 분해해야 한다.

2. 분해를 위해서는 육각 렌치와 납땜 세트와 몽키스패너까지 필요하다. 몽키스패너가 없어서 다이소에서 3천원짜리 구매함.

3. 분해 하면서 전선 케이블 색 확인을 위해 찍어둠.(아래 사진에서 검은색 케이블이 단선된 것을 확인.)

첫 번째로 수리를 했을 때에는 단선된 선만 이어 붙여보았다.

아래 사진처럼 초록색 선이 단선된 것을 확인하고 나름대로 꼼꼼하게 선도 여유 있게 이어 붙이고 수축 튜브로 마무리까지...

이렇게 해도 일단 동작은 했다.

정상 동작하는 것을 확인하고 집까지 타고가려고 하는데... 다시 레드링이 뜬 것을 확인했다.

확인 해보니 끊어졌던 부분이 다시 또 끊어져 버림..

2차 시도에서는 커넥터까지 바꿔 버리기로함.

사실 원래 달려 있던 커넥터를 빼기 위해서 아래 사진에 보이는 컨트롤러를 분해하고 싶었다.

열풍기로도 해보고 힘으로도 해보려고 했는데,, 모두 실패 했다.

결국 니퍼로 커넥터를 뜯어내고 열풍기로 납을 녹여 제거 했다..

그리고 새로 구매한 커넥터를 끼우고 다시 납땜함.

다행히 PCB 아래쪽에도 동판이 있어서 인두로 살살 납땜함.

5선 케이블을 찾아봤지만 주변에 6선 케이블 밖에 없어서 선 하나를 두고 사용했다. 6선 케이블은 전화선에서 많이 사용함ㅋ

아래 커넥터를 압착기로 작업하는 것도 쉽지 않았다.

5개를 하기 위해 20개 정도 사용한 것 같다.

또 맘에 안들었던 점은, 전화선이 좀 두꺼워서 아래처럼 고무에 끼우기 위해서 약간 칼로 구멍을 넓혔다..

아마도 고무가 더 찢어질 것으로 보인다...

다시 살림!!

커넥터 교체를 위해 구매한 부품 리스트

아이씨뱅큐를 좋아하는건 아니지만.. 부품을 찾다보면 아이씨뱅큐에 많이 있는 것 같은 느낌이 든다..

커넥터는 2.00mm pitch의 커넥터를 구매해야 한다.

2.00mm 커넥터와 호환되는 터미널도 함께 구매해야함.

구매 후에는 위 그림의 2번을 전선과 함께 1번에 넣어야 함.

1세트는 1번 1개, 3번 1개, 2번 5개가 한세트가 되니까 구매할때 참고하세요

참고로 위에꺼 구매할때 1,2번은 MOQ 100개... 3번은 10개였음..

커넥터 작업할때에는 아래처럼 생긴 압착기가 필요합니다.

압착기 싼거 1만원 이상, 위에 커넥터 부품 배송비 포함 1만원 정도.. 시간과 노력 등등을 고려해보았을 때

이 작업을 하실 바에는 사설 수리샵에서 메인 보드 박스를 구해하는게 좋을 수도 있음.

하지만, 한번 저 작업을 해놓으면, 나중에 단선되면 커넥터만 빼서 교환하기 편합니다.

http://v.youku.com/v_show/id_XMTY5ODAwMDkzMg==

Fastwheel F0 수리하면서 참고한 분해 영상

LoRa를 이용해 무엇인가를 만들려고할 때 App Key, App EUI, Dev EUI, LTID 라는 ID를 접할 수 있는데, 각 ID가 어떻게 사용되는지 알아보자.

아래 설명될 내용은 public LoRa 보다는 국내에서 서비스 중인 SKT의 LoRa에 맞추어 설명 되었습니다.

1. <LoRa Device>-<N/W 서버>

먼저, App EUI와 Dev EUI, App Key는 위 시스템 구성 예시에서 <LoRa Device>-<N/W 서버> 사이에서 사용된다.

디바이스가 LoRa network에 접속할 때(OTAA: over the air activation) 사용하는 ID와 activation key이다.

접속 과정에서 App EUI와 Dev EUI는 디바이스에 할당된 unique한 ID로 사용되며, App Key는 데이터 암호화를 위해 사용된다.

 App Key는 SSL에서 사용하는 인증서와 같은 개념이라고 볼 수 있다.

LoRaWAN Specification을 보면 APP EUI와 Dev EUI는 아래와 같이 정의되어 있다.

6.1.2 Application identifier (AppEUI)

The AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the entity able to process the JoinReq frame.

The AppEUI is stored in the end-device before the activation procedure is executed.

6.2.1 device identifier (DevEUI)

The DevEUI is a global end-device ID in IEEE EUI64 address space that uniquely identifies the end-device

단순히 App EUI는 서비스를 구분하는 ID, Dev EUI는 디바이스를 구분하는 ID라고 보면 된다.

다시말해, 만약 100개의 LoRa 디바이스를 사용한다면, 모든 LoRa 디바이스의 Dev EUI는 다르고, App EUI는 100개 모두 동일할 수가 있다.

App EUI는 IEEE에서 정의한 64bit Address로 되어 있으며, SKT로부터 서비스마다 할당 받게 된다.

Dev EUI는  IEEE에서 정의한 64bit Address로 되어 있으며, LoRa 칩 개발사인 Semtech에서 할당 받는다.

2. <N/W 서버>-<ThingPlug>

LTID를 조합하는 예제

• App EUI: 0000000000000004

• Dev EUI: ffffffff12345678

만약 위와 같은 App EUI와 Dev EUI를 가진 LoRa 디바이스라면 LTID는 "00000004ffffffff12345678" 가 된다.