今天上午的两个武汉航班很有趣。早晨预报武汉将雷雨，气象预报员说11点后雷雨可以过去。第一个航班原本8点左右起飞，被签派主动延误至9点之后起飞，以控制11点后落地。第二个航班原本的起飞时间就是9点15分，已经满足11点后落地的要求，因此没有延误。

最早的一份雷达拼图是8点的，由于没有得到更早的雷达图，所以我不知道早晨6点放行时的回波是什么样子，但是从8点的图上看，回波的前缘已经到达武汉，武汉已经TSRA，签派做出延误最早航班的决定肯定没有错。

然后，武汉从0800开始持续了将近5小时的中雷雨。

METAR ZHHH 220000Z 10003MPS 060V120 2800 TSRA BR FEW033CB 11/08 Q1016 NOSIG=
METAR ZHHH 220100Z 02002MPS 340V060 1500 TSRA BR FEW006 FEW033CB 10/08 Q1017 BECMG TL0210 TSRA=
METAR ZHHH 220200Z 08003MPS 1200 R04/1400U TSRA BR SCT004 FEW033CB 10/09 Q1016 BECMG TL0310 1600 TSRA=
METAR ZHHH 220230Z 10004MPS 1100 R04/1200D TSRA BR SCT007 FEW033CB 10/08 Q1015 BECMG TL0310 1600 TSRA=
METAR ZHHH 220300Z 13003MPS 070V160 1100 R04/1600U TSRA BR SCT006 FEW033CB 10/09 Q1015 BECMG TL0450 1600 NSW=
METAR ZHHH 220330Z 02002MPS 310V110 1100 R04/1200D TSRA BR SCT006 FEW033CB 10/09 Q1015 BECMG TL0450 1600 NSW=
METAR ZHHH 220400Z VRB01MPS 1100 R04/1600N TSRA BR SCT006 SCT030CB 10/09 Q1015 BECMG TL0540 1600 NSW=
METAR ZHHH 220430Z 10003MPS 1100 R04/1400N TSRA BR SCT006 FEW030CB 10/09 Q1014 NOSIG=
METAR ZHHH 220500Z 12003MPS 090V160 1100 R04/1600U TSRA BR SCT006 FEW030CB 10/09 Q1014 BECMG TL0550 1600 NSW SCT007 OVC040=
METAR ZHHH 220530Z 14004MPS 090V160 1500 RA BR SCT006 11/09 Q1013 RETSRA NOSIG=

下面是计划落地时间段内的SIGMET，信息之粗略，对放行和监控几乎没有任何帮助。

ZHWH SIGMET 1 VALID 220320/220720 ZHHH- ZHWH WUHAN FIR EMBD TS FCST N OF N28 TOP FL300 MOV E 20KMH NC

在此过程中，没有被签派控制的航班在0945起飞，1121正常落地。被签派延误的航班在1008起飞，最终因为雷雨备降了。两个相差20分钟的航班会有不同的结局，可见雷雨天气的复杂。

事后，我问了正常落地的那个机长。机长报告说在IKUBA之后就开始绕飞，高度层7800，向南偏40至50海里，然后右转过浠水，然后260度航向，04号落地。在下降到3600米时还有降雨，但落地时机场天气还是不错的。那个备降的机长报告在五边上有雷暴，所以备降了。其他信息没有再详细问。

下图是我根据飞行计划推算的航班过IKUBA时的雷达图

下图是正常航班落地时的雷达图

===================================================

问题：早晨的签派决策是否正确？

我觉得是正确的。在利用了所有的气象产品和信息后做出11点后到达的决定，肯定比9点半到达更安全。除非有一种更精确的气象产品可以准确预测雷雨结束的时间。

问题：雷达图真的对放行、监控有用吗？

我觉得有用，但是作用有限。因为雷达图滞后30分钟，而且并不精确，没有3维信息。它可以用来判断大尺度区域中影响发生结束的大概时间，但是不足以用来判断某地是否可以落地。

问题：签派是否有需要改进的地方？

我觉得目前没有，除非有一种更精确、更及时的气象产品。

问题：签派是否应该因为此类航班备降或主动的延误，而影响收入？

不应该！主动的延误的决策没错，放行前签派已用尽所有手段。

=================================================

最终还是那句话：“用准点率来考核签派的贡献，是一种脑残的制度。这种制度应该被坚决抵制。”

很早就听说国外有卖ADS-B接收器了，本来以为那是一种复杂昂贵的设备。就算是自制设备的价格不贵，说不定国内也很难能买到。

没想到，经过一番google之后，一个国外网站上说，在中国能买到一种数字电视棒，在LINUX中可以直接拿来接收ADS-B的信号。经过一番简单的安装后，果然成功。下面我就来介绍一下主要步骤：

第一步，电视棒的芯片型号是：RTL2832U+R820T，淘宝上一搜一个准。量多又便宜（价格小于50元）。

第二步，你需要下载并安装一个叫“rtl-sdr”的软件，网址位于：“http://sdr.osmocom.org/trac/wiki/rtl-sdr”。它是一个RTL2832U芯片的控制软件，负责控制电视棒频率（还有很多无线电方面的参数我不是很懂）。

第三步，就是安装应用软件，我只安装了一个最简单的，名字叫“dump1090”，网址位于：“https://github.com/antirez/dump1090”。他是一个把无线电中的数字信号提取出来并解码的软件。就是解码S模式应答机的内容。你可以运行命令：“dump1090 –interactive”。启动一个实时的列表，察看接收到的飞行信号。

最终效果如图：

图中可以看到飞机的航班号、高度、速度、经纬度和航迹，大约每秒更新一次。如果你想把飞机绘制在地图上，可以自己动手编一个软件，或者找一个现成的。

有人可能会担心信号问题。图中的结果是我在市区的家中接收到的，距离虹桥机场7公里，周围嘈杂而且高楼林立，所以只接收到1万英尺以上的飞机。我想如果我能带一台笔记本电脑去机场周边没有障碍物的地方信号会好很多。

以上这些内容中，最难的部分可能就是从源代码编译软件了。其实我在编译的过程中没遇到什么困难，只需要一些LINUX基础和编程基础就行。

我一直觉得在签派工作中，公司可以出资搭建这种简易的ADS-B接收器，分部在机场周围。在大面积延误或雷雨大雾时，可以精确地了解终端区里飞机的位置。

什么叫倒霉班？

就是在一天里遇到：
本场低云BKN001，备降无数；
某地侧风大，备降；
某地有活动，改走临时航路，长时间流控；
本场调机无数，长时间流控；
遇上个VVIP；
另一个地方侧风大，备降；
轮子见线，机务换轮子，造成机组将要超时，打一圈电话协调；
又是本场流控，改航路未果；
旅客生病，航班滑回；
雷雨返航；
平流雾备降；
飞机坏在某地多日回不来。

累死我了~~~

在淘宝上买了块天祥电子的51单片机玩玩，折腾了好久，终于在linux上搭建好了开发平台。我发现网上介绍linux中编写51单片机的流程很凌乱，所以下面做一下汇总。

我用的是ubuntu，首先用apt-get下载sdcc，这是一个编译器，安装很顺利。下面写一段简单的代码。如下，抱歉排版原因没有缩进：

#include <mcs51/8051.h>
void delay02s(void){
unsigned char i,j,k;
for(i=20;i>0;i–)
for(j=20;j>0;j–)
for(k=248;k>0;k–);
}

void main(void){
while(1){
P1_0=0;
delay02s();
P1_0=1;
delay02s();
}
}

注意这里的#include <mcs51/8051.h>。和Keil不同。接着编译命令很简单：

sdcc light.c

编译成功后会生成”light.ihx”。然后，找到一个叫”hex2bin”的软件，地址在戳。注意不是“hextobin”，那是另一个很搓的软件。让我走了很多弯路。

“hex2bin”要从源代码编译安装，还算简单。安装完后运行：

hex2bin light.ihx

它会生成light.bin。到这一步编译都完成了，就差把bin文件刷入单片机了。

找到一个叫“gSTCISP”的软件。这个软件编译安装的时候比较麻烦。需要手工改Makefile。

把单片机的电源关掉，把串口接上电脑，然后以管理员身份运行gSTCISP，如图：

选择好bin文件。然后点击DownLoad，然后打开单片机电源。bin文件就会自动刷到单片机里去，并开始运行。