[廣告] Ameba 阿米巴物聯網創意設計大賽


  •  活動名稱:Ameba 阿米巴物聯網創意設計大賽
  •  活動日期:2015-04-10 13:55 ~ 2015-08-10 23:55
  •  舉辦單位:瑞昱半導體

瑞昱半導體公司自2015年推出Ameba 阿米巴物聯網系統,可讓系統設計者輕鬆整合功能強大、介面完整又低耗電的阿米巴WiFi MCU於智能家居、智能照明、居家監控安防、醫療照顧等各種物聯網應用中。

 

了讓更多提昇人類生活品質,增加日常便利性的好創意能被開發出來,此次舉辦「阿米巴創意設計大賽」鼓勵全世界有創意的Maker、Pro-Maker、Startup將滿腦子的物聯網創意應用構想設計出來,讓世界更美好吧!

 

[競賽主題]

♦ 使用 Realtek Ameba 開發板(平台)開發各種創新應用。

♦ 使用WiFi通訊協定和其它平台 (Smart Phone, tablet, PC, Cloud, etc) 溝通

 

[競賽獎項]

♦ 冠軍 : 獎金新台幣 10 萬

♦ 亞軍 : 獎金新台幣 8 萬

♦ 季軍 : 獎金新台幣 5 萬

♦ 最佳校園創意獎 : 獎金新台幣2萬元 (得獎隊伍成員必須皆為在學學生, 含今年應屆畢業生)

♦ 入圍獎 : 獎金新台幣 1 萬元  (10隊)

 

[評分重點]

♦ 實用性:能夠被製造出來讓使用者使用,滿足使用者的需求或解決使用者生活中遇到的問題。

♦ 軟硬整合:透過成功整合軟體與硬體的產品設計,為使用者帶來全新的體驗。

♦ 跨平台整合:透過WiFi連網功能, 有效整合不同平台 (如:Cloud, Smart Phone, PC…等等)的服務 。

♦ 創意:與眾不同的想法或點子。

 

[參賽者資格]

♦ 每隊由1至10人自由組成且不得跨隊。

♦ 若全隊參賽者皆為在學學生(含應屆畢業生),可角逐「最佳校園創意獎」

 

[參賽費用]

繳交參賽費用後可獲得Ameba開發板一套

♦ 社會組: 1000元

♦ 校園組: 500元

 

[競賽方式]

  1. 初賽報名 (2015/05/20 截止)

(1)請參賽隊伍先於比賽官網登入會員進行線上報名  我要報名

(2)進行繳費 (以下兩方式請擇一付款即可)

  1. 線上信用卡付款:登入報名頁面線上付款即可。
  2. ATM付款:主辦單位將主動連繫參賽隊伍,告知匯款帳號資訊。

(3)參賽隊伍繳費完成後,主辦單位將寄發Ameba開發板給各參賽隊伍

註:優秀作品將受邀參加2015 年 Computex 成為 Ameba平台的展示作品

 

  1. 初賽投件 (2015/05/31 截止)

(1)請參賽隊伍利用Ameba開發板,拍攝物聯網創意應用之「概念影片」

(2)將概念影片上傳至Youtube (須於Youtube影片標題加註[Ameba阿米巴物聯網大賽] )

(3)於2015/05/31前再次登入至比賽官網報名頁面,補充以下欄位才算完成初賽投件

a. 提案概念文字說明(300字以內)

b. Youtube影片連結

 

[概念影片規則]

需能充分表達想要做的東西,且有機會能使用 Ameba平台實作出來

  1. Youtube上傳之影片標題開頭須註明 [Ameba阿米巴物聯網大賽]
  2. 長度限制:不超過10分鐘
  3. 影片須包含以下內容

-開發動機與構想 -產品說明 -實現方式

-創新之處 (與目前不一樣的地方)

-雛形/樣品展演

*不符合上述影片規格之報名案件將不予錄取

*是否牽涉到的專利,請參賽者自行查詢

 

  1. 初賽評選  選20隊進入決賽

(1) 主辦單位將根據參賽隊伍填寫之報名欄位、提供之資料完整度進行資格審查,並透過參賽隊伍上傳之Youtube影片,針對上述評分重點進行評選。

(2) 主辦單位將於2015/06/15前公佈20隊入選決賽之團隊名單。

 

  1. 決賽實作 (2015/06/15-2015/07/30)

請入選決賽之團隊進行成品實作,主辦單位將提供每隊一位技術Mentor進行技術討論一次。

 

  1. 決賽評選

(1)主辦單位將於2015/06/01-2015/06/14逐一拜訪進入決賽實作之20個隊伍進行面對面訪談,並根據隊伍提供之設計開發成品,進行產品創意/創新度(50%)、實用性/整體成本(30%)、完成度(20%)分數評選,選出優勝隊伍獲得豐厚獎金。

(2)主辦單位將於2015/08/10前公布前三名隊伍、入圍隊伍(10隊)、校園創意獎(1隊)。

 

[說明會]

主辦單位將於4/23(四)13:30 於台北華山文創園區舉辦一場創客交流會暨競賽說明會,歡迎有興趣夥伴報名參加、一起同樂!  

>>>報名說明會

 

[Ameba開發板Q&A]

Q: 我要如何取得阿米巴開發板?

A: 我們將於2015/04/23舉辦創客交流會,現場報名繳費後即可取得。或者您直接於www.ideas-hatch.com 比賽網頁點選”我要報名”留下連絡資料、完成繳費程序,我們將寄送給您。

 

Q: 如果我有不只一個好的創意, 能夠提供一組以上的送件嗎?

A: 可以的,只要您於官網登入會員帳號,報名不同提案名稱,繳費後再次登入補充提案說明、Youtube影片連結即可。我們鼓勵更多的開發,一組不限於一項創作。

 

Q: 在Youtube 送件影片,已經要用阿米巴開發板展示出設計的成果了嗎?

A: 並不需要,Youtube影片僅是表達設計理念,甚至如果用白板能說明清楚設計概念都可以(但必須清楚說明如何跟Ameba模組之哪個功能做串接)。

 

Q: 如果我有好的創意,但在把實體產品做出來有技術上的困難,瑞昱能提供協助嗎?

A: 可以,只要報名影片與提案文字說明能清楚將開發想法表達出來,作品就有機會入選,入選後我們就會提供技術討論與協助,盡量讓想法實體化。

 

[Ameba阿米巴開發板操作手冊]

附件1. 操作手冊

附件2. 軟體介接教學

附件3. 阿米巴Ameba_SDK (登入 Idea Hatch 會員後即可下載)

 

[客服資訊]

廖先生/ 03-578-0211#5378/ matthew@realtek.com

 

[主辦單位]

 

[協辦單位]

 

歡迎各界Maker、ProMaker、Startup丟創意、奪獎金!!!

>>>我要報名

QUIC 小註解

QUIC (Quick UDP Internet Connection) 是最近 Google 想要推的一個新的網路規範, 顧名思義, 它的目的就是快!

Google 有這麼多聰明人, 取名字自然不含糊. QUIC 唸起來和 quick 相同, 可以很直接地聯想在一起. 其實, 就算是這個 protocol 沒有用到 UDP, 歷史上也沒有發明過 internet, 都還是可以兜出 QUIC = quick connection. 哈!

那麼 QUIC 快在哪裡呢?快在兼具 UDP (User Define Protocol) 的輕巧, 以及 TLS (Transport Layer Security) 的保護.  UDP 的輕巧當然是相對於 TCP (Trasmission Control Protocol)  來的, 如果大部份都走 UDP, 當然傳輸速度就會增加, 讓我們複習一下.

協定 優點 缺點
TCP 可靠
UDP 不保證收到

簡單地說, 可以把 QUIC 解釋為 TLS + TCP 的改良版, 並且是用 UDP 來實現. 當然, Google 不會傻到撞牆, 傳了一路 UDP 又另外傳一路 TCP, 而是把 TLS 和 TCP 的內容包裝到 UDP 裡面. 所以按照下圖, TLS + TCP 可以通, QUIC + UDP 也可以通.  那 SPDY 又是什麼呢?這個晚點再說, 先假裝沒看到. 基本上它已經變成了 HTTP2 的一部分.

那麼, Google 宣稱的快速 hand shake 又是如何做到的呢?根據 [2], client 會先送 inchoate client hello 給不認識的主機, 主機也不客氣地回 REJ. 由於這個 REJ 裡面會帶有 source address 和 server certificates 的資料, 所以並沒有白白被拒絕. 這時再送一次 client hello (CHLO), 應該就會對了, 後續可能就會收到 server hello (SHLO) . 

或曰, 難道其他人都想不出有這招, 只有 Google 的人想得到? 當然不是這樣. 根據 TLS 的規格 – RFC5246 [3] 7.4.1.2, client hello 原本就要帶著一些資訊送給 server. 7.4.1.3 說 server hello 要回傳 client 看得懂的演算法, 或者傳 fail. 因此在現行規格下, server 可能根本不願意吐出資訊給冒冒失失的 client. Ref [2] 說:  They may be several rounds of inchoate client hello before the client receives all the information that it needs because the server maybe unwilling to send a large proof of authenticity to an unvalidate IP address. 

所以, 所謂的 0 round 或是 1 round hand shake 都是宣傳的噱頭. 這需要有夠傻的 server 願意配合才行. 一個捏造的 IP client 送一個小封包, server 就要大陣仗地把自己的認證資訊都吐出來, 這樣聽起來 server 很容易被攻擊耶. 除了這一步有風險之外, 後續的資料會受到 TLS 的保護. 根據 Ref [4], QUIC 整個 channel 都有加密.

根據 [5], 其實 QUIC 有考慮到被攻擊的事. 一個合法的 clinet 需要 proof of ownership of an address, proof of data received. 前者的精神是 server 會把一個值傳給 client, 看 client 是否可以回傳它. 後者的精神是, 通常網路攻擊就是 client 不理會 server 而瘋狂地送出 data. Quic 的相容性 SERVER 會檢查 client 到底有沒有消化過先前送出的資料. 做法是在某個特定的  bit 做 0/1 的隨機變換, client 要忠實地反映這個變化, 才算是真的 user, 而不是攻擊者.  

QUIC 另外有幾個優點在於: 用錯誤更正碼 (Forward Error Correction) 代替  TCP 的重傳, 減少重傳的數量. 事實上, 網路很好的時候幾乎都不會重傳, 網路愈糟, 愈需要重傳, 形成一個惡性循環. 因此 QUIC 基於 UDP 可以理解. 但假如 QUIC 把  TCP 幹掉了, 以後網路上都是 QUIC, 等到頻寬吃完了, 不就互相排擠, 讓 packet 掉光光? 

Well, QUIC 有兩招可以處理這個狀況 [5]. 他會送出 Congestion Feedback Frame. 這就像是網路頻寬金絲雀, 金絲雀死了, 就知道有問題了. 另外一招是測量  ack 的間距, 如果 sender 偷偷加速封包的傳送, round trip 的時間卻沒有拉大, 表示網路還很空, 還可以送快一點. 技術細節類似於 Linux 用的 cubic congestion algorithm.

[結語] Server 和 client 之間, 除了 internet 還有很多 router, switch, 如果全部更新是很大的商機吧!那某大網路 IC 設計公司會大漲嗎?哈!

[後記] 今天在 FB 上看到人家分享 QUIC 的文章, 重點倒也不是介紹技術, 而是捧 Google 的厲害. 雖然沒有寫什麼十三億人都驚呆了, 但是意思也差不多. 只講優點不講缺點之餘, 也沒有起到科普的作用, 只是打擊了一下工程師們脆弱的心靈而已. 台灣企業也努力過, 聯發科追過 Wimax 規格, 瑞昱試著訂 UWB 規格, 雖然都功虧好幾簣. 不過該做得還是可以再試一下, 也許有一天就成功了. 九陽豆漿機冠名贊助的真經上說過: “他驚由他驚, 大江閃星星, 他呆任他呆, 隨處有 WIFI." 在驚嘆之餘, 其實只要花一兩個小時就可以略跪門栓, 比一昧佩服人家然後驚呆來得好.

[ref]

1. TCP 與 UDP

2. QUIC Crypto design

3. https://tools.ietf.org/html/rfc5246

4. Quic Geek FAQ  

5. Risk Complete Failure