今年五月份刚刚结束博士答辩，带着爱人出去玩了一圈算是弥补一下一直亏欠她的结婚蜜月旅行，然后就匆匆忙忙办理各种回国的事宜，退大学公寓，处理银行支票本，递交归国留学人员证明的申请，好在六月初一切都办妥了，买好机票踏上回国的旅途。很感谢那天前来送我们的杰哥和鹏鹏，小克虽然中国学生很少，但一个实验室里的几位华人师兄弟还是很有情谊的，也许以后他们几个当中肯定能出个教授甚至老总什么的，毕竟都是有才华还勤勤恳恳的老Geek，哈哈。
其实2015年的事情出奇的顺利，两位博导中，一个柬埔寨裔导师（称他为老HOU）想多留我半年给他写代码，另外一个纯法国导师（叫他JP好了）觉得这样做不妥，说什么奖学金都没了，必须让学生尽快毕业云云，两个人听说为此掐架了好几次，结果也是比较倾向于我的利益，只把我的答辩延期了半年左右。可是我对自己的论文却并没有那么的有把握吧，搞物联网协议这方面的科研工作是有些虚的，做的人也不多，至今我也没弄清楚是理论研究工作多一些，还是写代码的工作多一些。理论说白了就是概率论+网络拓扑学，是计算机网络中很基础的东东，有几篇文章，但都不算有名，可以拿来做几个公式出来，大致描述一下自己设计的路由协议。但为了能验证自己的那一丁点工作，实现在硬件上的工程量是很巨大的，本想着去年带个中国硕士实习生能帮我的论文打个基础，结果却是我帮他又是造假又是瞎编地让他混毕业了，看着自己写的博士论文硬着缺了两个重要章节，当时不禁感叹自己心还是太软。
答辩总是要尽早答的，越拖越对自己找工作等事情不利，可是论文还是缺实际系统的验证，这点确实是难以避免的硬伤了。年初的时候，两位导师达成了一致，说你把优化后的IETF RPL协议实现在组里做的硬件平台上，做几组现实环境的实验，把论文写完就让你毕业吧。可是怎么做呢？当时真有种想放弃的念头，不过有个开源的嵌入式系统Contiki可做参考，又有个几年前的关于AVR处理器C代码框架，也算是不幸中的万幸了，有了参考终于有个从网络模拟器Cooja和NS3转到实际硬件平台上的勇气，但在这中间还是吃了不少的苦头。
首先，没有帮手，虽然一直在自诩是搞嵌入式软件系统的，但并没有在企业干过，也没参与过什么项目，一直在学校的实验室混导致一个人根本搞不出来什么能实际有用的东西，或许做个系统出来压根也不是一个人的活儿吧。
其二，虽然有参考，但师兄们做的无线传感器节点硬件平台，其复杂度还是远远比参考框架大许多，不得不移植许多Atmega128RFA1原来ZigBee协议栈的底层代码，包含I2C、GPIO、Usart的代码，又要加上了Decagon、Lm75、tsl2550d这样农业环境采集传感器的代码。
其三，Contiki系统的版本跨度有些大，尤其是2.x以后，每个版本的接口都或多或少的有些简化，连不少自带协议栈的接口都变了，虽然使整个系统平台得到了优化，但对于Atmega128RFA1这类古董级芯片的支持代码，已经不会再有后续的开源项目去跟着Contiki团队的改动去继续做了，好吧，工作量继续不断地再加，好在不需要把Contiki整个协议栈都改一遍，但底层的MAC层，尤其ContikiMAC这样比较新的，又自带休眠模式的RDC层，肯定是要移植的了。
其四，无论是使用Cooja的MSP430当模拟节点去做仿真，还是用NS3这类高大上的专业网络仿真器，其实都有个问题，没办法很方便的把改好的RPL代码移植到硬件平台上，或许Cooja本身就是Contiki平台的一部分，略微能减少一些工作量，说到这里不得不佩服设计ContikiRPL的两位思科的大神，对Metrics和Objective Function的接口设计得好，也让RPL路由模块相对地从协议栈中独立了出来，不至于再去把uipv6全部重新改一遍了。
当时考虑到这里，发现基本没办法在两三个月内就把代码移植工作和节点部署实验工作都做完，那就简化吧。Decagon土壤湿度传感器去掉，只留下电压、光强、温度三个传感器，每个传感器设计一个Contiki process，系统可靠性检测模块卡了好久，其实我到现在也没有完全理解为什么要在小节点上做多核，或许这就是科研的意义所在吧，做的就是个新意。本来想继续简化把ContikiMAC去掉，改用nullMAC，但转念一想，没有休眠，怎么让节点在小树林里跑一整天呢？想想那段时间几乎是每天都工作到好晚，甚至用断了一根JTAGICE II的调试线缆，好吧，我承认是我拔来拔去太用力了。
二月份的一天，老HOU跑过来看我的工作进展，我用一个组里做的MiLive硬件节点做连接CollectView的Sink设备，用ContikiMAC+原RPL模型+uIpv6+UDP APP做了一个小数据采集demo，连了两个Sender节点组了个星状网，结果他有点儿目瞪口呆的感觉，支支吾吾问，你是怎么在这几个月就能做出来的呢？我心里想，这不都是你逼出来的吗？但是口里讲的还是组里的师兄如何如何帮忙，Contiki+Cooja的平台多么多么方便开发，反正细节他也不在乎，只要把传感器数据传上来，实时显示出来，对这个RPL模型实验平台来讲已经是不小的进步了。之后的工作就是调整整个系统的稳定性，总不能费半天力气在树林里折腾部署完节点，跑十分钟就都挂了是吧。这就靠疯狂地烧写程序，然后先放在办公室里测，没测几次，就发现如果组多跳无线网络时节点有一大半会在7个小时左右挂掉，然后大约在10个小时左右全部都Down掉，这里指的是节点发送的数据包都接收不到了，但Led闪烁的进程还在跑着。后来猜测是其中一个传感器数据采集进程的延迟比较大会与ContikiMAC里的中断产生冲突，把进程控制的代码做了些调整，总算能让系统稳定地采集三四天的环境数据了，仅仅修复这一个问题就差不多测试了两周左右。但距离完成还是很远很远啊，RPL路由的双向通信怎么办呢？Contiki里面的Simple UDP应用没有这块呀，转念想起来不是还有个老掉牙的Shell嘛，也把这个应用进程移植过来，到最后发现自己的代码写得很乱，完全没有按照Contiki规定的，外围驱动放在Platform代码里，MCU驱动放在CPU代码里，整个MiLive嵌入式部分的软件系统像一个大拼盘，充斥了各种设计不良的进程，但最终Atmega128rfa1的Ram居然没有被玩没了，也真的是万幸了。
好不容易调完了双向通信（下行包其实很不稳定，容易跟随机发包的数据采集进程发生撞车，Shell需要添加几个新指令），兴冲冲地找小老板要防水盒，一看就傻了，这么大一个盒子，由于是真的放在野外环境下的，要三防做到最好，每一个都是分量十足，而且完全密封，等等，那天线怎么办呢?就算是塑料不会让信号衰弱，但把盒子直接放在坑坑洼洼的小树林里，多数直线视距信号会被土壤吸收掉，钻个孔把天线伸出来，抱歉，暂时没有室外用的天线，只有室内用的是2.4GHZ的小天线，想买新天线，要走采购等等一系列流程，没个两三个月可下不来。让我再等两三个月？索性自己想办法吧，天线高度不够，那就找纸盒垫高一些吧。结果碰上小克连续两周下雨，二月份的冬雨，小树林里没有路，只能踩着泥走，更要命的还是一个人得抱着10个节点和密封盒，早晨去部署节点，傍晚还要把节点收回来。垫高用的纸盒遭到雨水的浸泡后很快会变软，然后...密封盒就掉下来，一旦掉落，那节点的数据丢包率就可能接近70%，时间积累到一定数值就会影响ETX的计算，按照原有RPL的算法整个路由拓扑就都会变了。另外还有一个问题，就是室外环境很难去预测，节点周围全是各种形状不规则的植物，不平整的地表，另外还有几个建筑物，而Sink节点就放在一个建筑物的阳台上，十个节点分布在足球场大小的树林里，其实节点部署还是人为设定的吧，尽量考虑到了覆盖面积。在做了两次很不成功的部署实验之后，我就直接被冻发烧了，在此还是建议做无线传感器野外环境部署实验（智能家居、室内走廊、停车场这样的部署现在看还是相对容易的）的兄弟们准备双防水的户外登山鞋和一件冲锋衣吧。
就这样反复折腾了十几次，就在孤立无援筋疲力尽之前，凑足了很像样的五组数据，每组大约测了八九个小时的数据采集，期间由Sink节点随机发送Ping指令给所有Sender节点然后统计Reply的百分比，本想用Matlab做进一步处理，但还是为了节省时间，用Excel画了几个简单的结果曲线。也许到这里算结束了吧，其实部署实验只做了一半，因为这只是RPL标准路由模型的实验结果，优化后的模型还没有做呢，都做出来才能做比较呀，不过后来由于经验多了，实验做起来也顺利了不少，但还是在这做实验的一个月内费了一双登山鞋。
现在想想那时候的工作，也算是一种锻炼吧，能自己扛的时候尽量去扛，收获也会很多。有时也很庆幸自己不是靠写文章毕业的理论型博士，多一些工程经验对自己后来找工作还是非常有帮助的。