题外话

近期因为SA2 Study on Traffic Logical Status Awareness的new SID立项的缘故和大家作沟通，SA2各位专家的意见都很真切，我会尽量完善，在此先谢过了。

不过，再忙，既然说好的事情，该有还是要有的：有自动同步功能的3GPP_FTP_Downloader v3.0 来了！

下载地址：
链接：https://pan.baidu.com/s/14Bt4M1vLhi973BuWrg_WhQ
密码：znhe

同步功能

马上就要开会，闲话少叙。基本的使用功能就不多说了，可以参考这篇和这篇。

这里主要介绍一下同步和自动同步功能。

Sync Now 同步功能属于一次性的功能，会自动下载所选会议目录下的所有文件（包括子文件夹下的文件）。如果有文件已经存在，并且大小一致，将不会重新下载。

同步操作下载的文件会保存在应用程序所在目录的/会议名称/目录下。

AutoSync自动同步功能将会按照设定的时间（默认30分钟），设定一个计时器。当计时器结束时，触发一次上述的同步操作，并启动一个新的计时器。

自动同步开始后，会有提示。

再次按下自动同步按钮，会停止自动同步。

即使开启了自动同步，如果你想马上进行同步，也可以按Sync Now按钮，马上进行同步。

但是如果目前正在进行同步的操作，那么当前的同步下载过程将会继续进行，只是在本次同步结束后，才会更新新的状态（例如停止自动同步，或者进行新的同步）。

此外，这次windows版本增加了状态窗口，可以看到程序的运行状态信息。

写在最后

希望大家能够支持和co-source我们的研究立项， Study on Traffic Logical Status Awareness, S2-183763, S2-183767，非常感谢：）

惊不惊喜，意不意外？软件更新了

首先，非常感谢大家的关注和反馈。3GPP FTP Downloader作为一个非常小众的工具程序，能有3位数的下载量，其实已经大大超出我的预期了。

这段时间，参加了Reno和Montreal的两次会议，我也对这个小程序进行了评估，发现了几处不尽如人意的地方。距离下次开会时间还早，本想偷偷懒，但是精神洁癖似乎又发作了（其实是因为一不留神，就到写稿的Deadline了），于是意外地有了这一次的提前到来的软件更新。

这次更新包括了Bug修正，文件下载功能完善，以及新增了文件的通配符匹配方式。下载地址：https://pan.baidu.com/s/1-nVwArIehE82TIeNOALH9g

包括：mac、win_x86（32位）、win_x64（64位）版本以及新版的JRE。

启动方法和之前的一致，请参考有用功：3GPP提案下载太烦了，怎么破

1 Bug Fix

有同学提到了的这个bug，我也遇到了。对于还没有更新到服务器文稿，会生成一个无效的zip文件。在这个版本中，会检查文件的下载状态，避免这个情况的发生。

2 功能完善

增加了对会场local FTP中文件和public服务器上Meetings_3GPP_SYNC目录中文件的下载；
改进了文件查找方式，可以进行子目录的迭代查找，这个特别适用于下载会场提交的Revision的文稿，这些文稿有的被放在inbox目录，有的被放在update_01，有的被放在update_02；
增加了配置文件的自动生成功能，避免程序启动发生意外；

第一项改进并不是新功能，访问Local FTP可以通过手动（manual）的方式来实现，访问Meetings_3GPP_SYNC可以通过编辑配置文件实现，但是在开会的时候，发现还是做成可以直接使用的方式比较轻松，可以尽可能地减少键盘操作，尽可能不要打断工作思路。

手动模式在设计的时候，主要考虑是应对一些突发情况和需求。但是，在实际使用中我发现意义并不大。在未来的版本中，可能会考虑将手动模式的选项去掉。

文件查找方式的改进源于下载Revision文稿时发现的一个问题：由于秘书会适时地整理会场提交的新文稿，因此虽然大家都会上传到inbox目录，但是可能到了讨论的时候，提交的文稿已经被移到了诸如update_01这样的临时目录中，或者被放要求放进Draft目录；这对下载某篇特定文稿来说，会造成相当的困扰。更新后，下载文件变得更加无脑化，简单讲……你就让程序自己去下载吧。另外，顺手把FTP服务器文件路径的配置文件也改为自动生成了。

3 新增功能

这次更新最重要的部分是增加了对*通配符的支持。这个新增功能源于一个看起来特别不起眼的事情：查看Agenda。因为要在不同的会场来回跑，因此总是会比较关心主会场Agenda的调整情况。但是，人不在的话，并没有办法及时知道当前Agenda更新的什么版本了。所以，最偷懒和直接的办法，就是把所有的agenda都下载下来，不论是发布在Agenda目录里的，还是Draft目录里的，统统自动撸下来。然后再看现在到哪个版本了。

引入通配符，下载就完全不用关心目录结构这种事情了。

以上面提到的下载Agenda为例：不用区分大小写，在file list里面填上agenda再加上一个*号，按Download，就可以了。

同样，这个功能也可以用来查找并下载其他的文件，例如：Frank的ChairmanNotes：

目前程序里的通配符功能非常初级，仅仅起到一个标记的作用，也就是说输入agenda* ，*agenda，甚至agen*da，效果是一样的。（需要正则表达式的同学，请举手告诉我）另外，为了防止意外下载，在程序中也做了文件数目限制，如果单个文件夹内通配符匹配到的文件数目大于100个，那么就不会下载。

4 提问时间

有同学留言：

在会场的时候，我也会使用类似的方法，使用everything这样的软件来进行本地检索（macos: spotlight + alfred），这主要是因为开会时候一篇一篇过提案，基本就是跟着主席的节奏走，讲到哪篇跟到哪篇。但是，在会前做Contribution Review或者或者会后整理Report的时候，我还是更倾向于用这样一个工具将一个专题的文件集中下载存放在一起后再操作。同一个主题的文稿放在一个文件夹，再配合一些辅助手段（例如，macos的快速预览功能），不论是阅读还是作批注，比起用搜索引擎按照编号一遍遍反复查找到文件后再处理，都会方便很多。

还有同学留言：

这些情况基本上都是与系统安装的jre版本有关。基本上下载和使用和系统对应的JRE能够避免很多稀奇古怪的问题。我也会尽量多在windows下进行一些版本的测试，就像这样：

以上就是全部内容，如果使用中有任何问题，欢迎给我留言。

See you in Sanya!

关于迭代器，血的教训

对容器内元素进行修改，共有3中方法：

vector<int> vec_a;
vec_a.push_back(123);
vec_a.push_back(123);
vec_a.push_back(123);
vec_a.push_back(123);

vec_a[1] = 234;

vec_a.at[1] = 234;

vector<int>::iterator vec_a_iter = vec_a.begin() + 1;
*vec_a_iter = 234;

血的教训就是：在用=的时候，一定要知道对C++来说，很多情况下=是进行赋值，而不像Java一样，取得了对象的引用！

int a = *vec_a_iter;
a = 456;// a 从234 变成456
cout<<a<<endl;
cout<<*vec_a_iter<<endl;

这时候，*vec_a_iter是没有发生变化的。

记住：对容器内元素进行操作，就上面3中方法。如果用迭代器，老老实实的用(*iterator)来操作，不要偷懒！

有用功：3GPP提案下载太烦了，怎么破？

每次开会，都会跟踪几个研究方向。通信汪的日常，需要在会前做contribution review。

5G的饼越画越大，汪们无比激动，提案数目成倍增长。每次开会动辄上千篇提案，提案的编号都要升一位才能解燃眉之急。

看着翻了N屏还没到头的TDocList，汪同学的内心是崩溃的，眉头拧成了疙瘩。

下载需要看的提案，在3GPP的FTP上都不知道要翻多少遍，想到这些，汪同学不禁在心中又使劲骂了一遍：

“这哪儿是人干的活计！”

“看提案才是你汪该干的事儿，下载这种粗鄙的工作，就应该让那电脑干，反正咱也不用交电费！“”

码农斯基似乎洞悉了汪同学的小心思，探头过来搭话。

二人对视，会心一笑。

如果只是做Contribution Review，通过下面这个简洁的Work Flow和一个有效的工具，就可以把想看的内容单独收集起来。

Workflow的内容很简洁：收集、批量下载、自动保存。需要人做的事情就是收集阶段，从TDocList中筛选出提案号。而剩下的工作就交给3GPPFTPDownloader来做了。

下载地址在这里，区分系统哦。

Step 0：启动程序

系统上需要安装JRE。对于Windows系统，双击jar文件就可以启动；对于Mac，拜教主和厨子所赐，需要在终端中启动：


  java -XstartOnFirstThread -jar xxx.jar

程序启动后的主界面如下：

FTP Server：FTP服务器的url或者ip
Meeting Type：3GPP工作组
Meeting Name：某个工作组下的具体某次会议
Remote URL：FTP文件路径
File List：需要下载的文件的名称

Step 1：选择工作组

通过下拉菜单选择3GPP的某个工作组。之后，程序会自动更新这个工作组内的所有会议名称信息。

Step2：选择会议

Step3：添加提案号并下载

添加需要下载的提案号，每行一个。之后点击Download便开始下载。文件会自动保存在”程序所以在目录下/会议名称/当前日期和时间” 目录下。

Tips：

通过点选Manual，可以手动编辑ftp服务器和文件路径。
目标路径并没有指定到服务器的Docs路径上，因此，可以下载某次会议目录下的所有文件。例如，想要下载某次会议的meeting report或者其他zip文件，只需要选择某次会议后，输入会议报告的zip文件的名字（去掉.zip)，就可以直接下载了。这和前面介绍的下载提案的方法一样。
通过修改程序目录下的meeting_path_cfg.cfg，可以自己定制需要呈现的工作组。格式：工作组的名字@ftp服务器上的路径，例如：SA2@/tsg_sa/WG2_Archd；增加、删除都可以，例如增加一行：LTE@/tsg_ran/WGs_LongTermEvolution
如果你偏爱脚本，可以尝试我以前写的一个shell脚本，没有GUI那么方便，但是体积小巧。

也谈Solidworks 打开部件时无法载入GdtAnalysisSupport.dll问题的解决方法

通过在百度搜索，很多（绝大多数）中文网页解决这个问题的方法其实都是同一个：解决Solidworks和Windows Update KB3072630冲突，

解决的思路大体上如下：

1.打开注册表，修改或创建

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer

2.创建32位DWORD键值“RemappedElevatedProxiesPolicy”，并设为1

3.修复安装Solidworks

4.安装完成后，将上述键值改为0

但是，这个方法有个前提：确定问题是由于KB3072630冲突造成的。

可是如果你在Windows Updata历史中，发现压根儿就没有安装过这个补丁呢？很遗憾，你中彩了，各种网站竞相转载的上述解决方案，对你是无效的。

在Solidworks的论坛上，还有另一种解决方案：

1) Go to windows ‘Start’ > type cmd

2) RMB on ‘cmd.exe’ > select ‘Run as administrator’

3) In windows explorer Navigate to <SW installation folder>, (where sldworks.exe is contained)

4) Drag and drop ‘sldworks.exe’ in command prompt and type

/regserver

Typically the command would look like

“C:\Program Files\SOLIDWORKS Corp 2013\SOLIDWORKS\sldworks.exe” /regserver

5) Press ‘Enter’ > this will register ‘sldworks.exe’

6) Reconfirm behavior.

简言之，用管理员身份，在启动sldworks.exe后面跟一个参数 /regserver

问题解决！

IoT的世界，谁能笑到最后？

3GPP在上周更新了主页，在显著的位置更新了3GPP三个IoT通信技术标准的进展情况。这一方面顺应了6月份NBIoT标准化的完成，体现了3GPP对于物联网技术标准化持续的重视；另一方面，也展示了3GPP对于以NB-IoT为代表的这一系列标准的信心，仿佛已经坐定了半壁江山，要笑看风起云涌。

IoT市场确实会风起云涌，但是，谁能笑到最后呢？

鸟瞰IoT的世界

设备和设置之间能够在不经人为干预的情况下进行（无线的）数据通信是物联网的基础。按照设备间通信距离的长短，可以把物联网通信技术一分为二：一类是目前普遍应用于智能家居设备中的固定及短距离通信技术，这类技术的代表是ZigBee、WiFi、NFC等；另一类是以智能抄表为典型应用场景的广域网传输技术，统称为低功率广域（Low Power Wide Area，LPWA ）IoT技术。

这时我们还没有看到3GPP的影子。继续根据使用的频谱的授权情况，LPWA IoT技术可以细分为以LoRA、SigFox为代表的使用非授权频段的技术方案，以及工作在授权频段上的技术方案，这一类技术方案的代表就是工作在蜂窝网频段中的3GPP E-GSM-IoT，eMTC，NB-IoT。

如果从实际应用的角度来看，固定及短距离通信，占IoT通信连接总数量的70%以上，剩下不到30%采用LPWA IoT技术进行连接。

所以，从总体上看，IoT的世界大概是这样一个情况：

3GPP的LPWA-IoT世界

LPWA IoT技术需要满足4个需求：

长电池寿命：在满足每天小数据量交换的情况下，有至少10年的电池寿命；

低成本：IoT业务可能只能带来传统移动通信业务1/10甚至更低的ARPU，因此IoT设备必须非常廉价，同时部署IoT设备的成本也必须低廉；

覆盖增强：IoT设备可以部署在相对极端的环境下，例如地下室、电梯中，因此链路预算必须增加以应对额外的穿透损耗，例如增加一堵墙。

支持海量链接：实际应用中，IoT设备的增长速度会远超其他移动通信设备（如手机），并且分布可能非常不均匀，因此LPWA IoT技术必须支持海量终端同时连接。

针对上述条件，3GPP发布了三个通信技术标准：

基于GSM，针对IoT优化的E-GSM-IoT；
基于LTE，针对IoT优化的eMTC；
基于窄带LTE，对IoT优化的NB-IoT；

三种标准的技术对比见下表：

下面这个图看起来，可能更加直观：

不难看出，工作在GSM频段内的E-GSM-IoT从技术性能的层面上，已经可以满足LPWA-IoT的需求。事实上，现今工作的LPWA-IoT设备中，60%~80%都工作在2G频段。但是，随着全球运营商已经开始推动蜂窝网络向5G演进，蜂窝网频段内LPWA-IoT技术方案的演进将不可避免。与此同时，市场的变化也会加速这种变化。

IoT的世界，谁能笑到最后

到2025年，采用固定及短距离通信技术进行通信的IoT设备仍然将占据绝对主要地位。但是分析也同时指出，LPWA-IoT设备数量的增长，也将非常可观：

（Cisco Visual Network Index 2016 Global Mobile Data Traffic Forecast Update, 2015–2020 White Paper.）

蛋糕很诱人，但是对于LPWA-IoT来说，市场却存在非常多不确定性。

首先是授权频段和非授权频段技术阵营间的竞争。虽然从目前的情况来看，运营商会在蜂窝网授权频段中采用3GPP标准化的IoT标准，例如NB-IoT，是一种技术演进必然的选择。但是，就如同高级饭店的大厨为了不出闪失，每次做菜一定都会规规矩矩地按照菜谱操作一样，运营商采用标准化的在授权频段工作的IoT技术方案，本质上只是一种“套路”，一种和推广2G/3G/4G网络相同的，“可控”且“安全”的套路。其实不仅仅是针对IoT市场，对于作为服务提供者的运营商来说，不论何时，金主爸爸才是唯一的上帝。工作在非授权频段的LoRa或Sigfix，和工作在授权频段的3GPP的E-GSM-IoT、eMTC、NB-IoT并没有高低贵贱之分。

另一方面，从技术的角度来看，对于非授权频段的技术方案来说，除了有来自在躲在授权频段这个保护伞下的技术方案的竞争压力，一个更为残酷的事实是：非授权频段的技术竞争是真正的丛林竞赛。由于没有频谱限制的门槛，永远都会有新的竞争者加入进来；而对于工作在授权频段的3GPP的一众标准及其未来演进版本来说，未来是不是有足够多的细分市场来养活多个标准，以及对市场需求预测的不确定性和标准化进程周期间存在的失调的可能，也将造成困扰。

IoT市场里谁能笑到最后呢？答案很可能是这样：

IoT市场就好像一锅八宝粥，虽然表面看起来平平常常，一览无遗，但只要勺子在锅里一搅，就没准儿突然舀上来颗枣，或者一种没吃过的豆子来。

动手玩：这些信号你见过多少？

SDR posts

前言

无线通信之所以让人着迷，是因为透过电磁波这种人类几乎无法感知的介质1，在我们呼吸的空气中、在我们生活的空间，我们人工构建了无数设计精巧的无线信号，这些无线信号籍着同样精确而复杂的通信协议，承载了人们移动生活的几乎全部信息。这是一件默默无闻，却又无比伟大的事情，意义重大却又带着浓重的神秘感。

无线信号就是人赋予无线通信的生命。通过RTL-SDR，现在可以轻易地一窥其中的究竟，在近乎无限的信号空间（其实，是有限的，毕竟无线通信使用的频带还是有限的），像哥伦布发现新大陆一样，发现那些优美、高效，并且肩负重任的无线信号。

那些美丽的信号

由于人类对绝大部份无线信号都不能直接感知，为了增加更加直观的“实在感”，接下来，将通过瀑布图（Waterfall）的形式，从时域(纵轴)、频域（横轴）以及能量（颜色）三个维度来认识一些与我们生活息息相关的无线信号。

（模拟）救生／定位信标

这就是我们经常在Discovery等探索自然的节目中见到的用来在海上定位沉船的浮标，以及用来定位落水人员的浮标发射的信号，图中这个是模拟信号。数字信号版本远没有这个模拟信号壮观，于是没贴，:P

OFDM信号

这个就不用多解释了吧，教科书一样经典，不过不是很完美：瀑布图（下半部分）的波动大概是因为画的时候，调整了SDR接收机中心频点的缘故？

GSM信号

历史悠久的2代移动通信系统。之前的动手玩：OSX下配置基于RTL的SDR中，已经把这个信号从接收到解码全过了一遍。当然，人家截的这个图更加标准，貌似还有业务，真好。

再贴过神物，德味老式GSM电话。话说，BOSCH这家公司也真是NB，小到家用电器，大到工程机械，居然连手机都做（过）。（上次去罗德交流，也是这个感觉，大概这些德国公司都这个风格）

LTE信号

4G LTE(下行信道)信号看起来是这样的：

信道的放大图，话说图里那些跨了整个带宽的部分是PDCCH信号吗？

MFSK调制信号

MFSK调制是一种普遍使用的调制方式，在业余无线电系统中普遍使用。下图是MFSK-8信号，看起来像某种生命形式，有没有？如果生命存在的意义（之一）就是承载并传递信息（遗传信息），说这个MFSK有（人工）生命体的特征似乎也不矛盾。

DECT(家用无绳电话)信号

数字增强无绳通信(Digital Enhanced Cordless Telecommunications ，DECT) 系统，是由ETSI(European Telecommunications Standards Institute)制定的增强型数字无绳电话标准，主要用于无绳电话系统，基于TDD方式，帧结构采用TDMA（据说也有FDMA的）采用DQPSK调制。采用DECT标准的设备几乎全球通用，但是根据美国FCC的要求，为了避免和北美地区使用蜂窝通信系统造成相互干扰，在北美的DECT系统要工作在1920 – 1930MHz频段，因此在北美地区单独使用“DECT 6.0”标准，这也造成了同一个品牌的产品，销往欧洲的和销往北美的不通用。

DECT的更多技术细节可以参考ETSI EN 300 175-2

PAL制式模拟电视广播信号

用过模拟老电视的同学应该都对这个有印象。PAL （Phase Alternating Line）逐行倒相是一种模拟电视广播信号的调制方式，对应的还有NTSC（以National Television Standards Committee，国家电视系统委员会缩写明明的制式，一看就知道是老美的），和SECAM（Sequentiel Couleur A Memoire，塞康，顺序传送彩色与存储，顺序与存色彩电视系统），不过现在已经不多见了，因为模拟广播电视已经普遍被DVB（数字广播电视）所取代了。

看到PAL，又勾起了一些往昔学习信号与系统以及通原时的记忆：DSB，SSB，VSB……

UTC授时信号

UTC的全称是协调世界时系统。采集的这个信号发自于美国的NIST (National Institute of Standards and Technology) 。

以下来自度娘：

由于国际原子时的准确度为每日数纳秒，而世界时的准确度为每日数毫秒。对于这种情况，一种称为协调世界时的折衷时标于1972年面世。为确保协调世界时与世界时相差不会超过0.9秒，在有需要的情况下会在协调世界时内加上正或负闰秒。因此协调世界时与国际原子时之间会出现若干整数秒的差别。位于巴黎的国际地球自转事务中央局负责决定何时加入闰秒。一般会在每年的6月30日、12月31日的最后一秒进行调整。

但是UTC这个名字却颇有意思，因为按照英文来翻译，协调世界时是Coordinated Universal Time，缩写理应是CUT。但是按照法语来翻译缩写却是Temps Universel Coordonné，TUC。为了折中CUT和TUC这两种写法，所以索性就改成了UTC，谁也不得罪 XD。至于为什么是法语？前面提到，国际地球自转事务中央局不是在法国吗？

VOR信号

VOR全称是甚高频全向信标（Very High Frequency Omnidirectional Radio Range）也叫伏尔导航系统，是一种用于航空的无线电导航系统。VOR的工作原理是通过比较位置已知的地面导航点发射的两个30赫信号的相位，来确定飞机相对导航点的磁方位角。这个信号采集自美国。

估计一般人都没有听说过VOR系统，因为一般人（包括我），在日常中真得很难感到它的等存在。之所以会把它列在这里，是因为一次偶然的经历，我见到了这样一套天线阵列系统：

当时还不知道VOR是啥，第一个感觉：这不是Massive MIMO吗，居然还是个环形阵列，有创意！第二个感觉：不对，建在这荒郊野岭的，不会是用来抓外星人用的吧（开始YY了）？第三个感觉：我不会是看到什么不该见的东西了吧….赶紧走。实际上，只要你坐过飞机，VOR系统就曾经为你的飞行安全服务过。VOR系统是引导飞机保持航向，近进、进场的重要系统。虽然现在的飞机，例如大型客机，普遍都装有惯性、GPS等更加先进的导航系统，但是VOR仍是每架飞机必备的导航装备。

数不胜数

雷达、遥测遥感、遥控车钥匙、蓝牙、WiFi，在我们身边的无线信号是数以万记的，这些还仅仅是一小部分，那些用于特殊用途的无线信号例如用于军事、外交用途的无线信号，则往往更加隐蔽，难得一见（见着了就麻烦了，哈）。

就像我们去参观博物馆、参观工厂一样，我们要带着这样的心情去看待这件事情：无线通信是人类文明和工程的杰作，RTL-SDR给一般人打开了一扇欣赏和了解无线通信的窗口，使更多的人能够对无线通信产生兴趣，让更多的人愿意去了解这门工程科学，这是一件多么有意义的事情！

严格来说，人类是可以直接看到可见光，也可以在一定程度上感觉到红外线等特定频段上的电磁波，但是这部分电磁波在整个电磁波频谱中只占极小的部分。 ↩

动手玩：RTL-SDR FM Radio Walk Through

写在前面

自从在OSX上装好GNU Radio之后，我一直在想能不能搞点有意思的刺激的东西。但是，饭总要一口一口吃，大的计划也要脚踏实地地从一些基础工作开始做起。在开始自己写代码前，最好用现成的东西先来一遍，看看标准的代码长什么样。俗话说，老司机给带带路呗。所以，这次我们就利用GNU Radio已经提供的blocks，搭建一个FM收音机出来。

准备工作

硬件方面，我依然钟情于40块钱的RTL，像X310这种板子，用来当背景什么的最合适了 XD。其实最主要的原因是，万一玩儿脱了，也就40块钱，要是把X310烧了……呸呸呸

软件方面，在前一次配置GQRX的过程中，我们已经在利用macport 在OSX中搞定了GNU Radio的安装，但是为了稳妥起见，还是用macport把各种乱七八糟的东西更新一下。如果和我一样，有些组件已经给玩坏了，还可以强制重新安装一遍。

1.sudo port selfupdate2.sudo port update installed

如果更新过程中，收到这样的提示：

1.Warning: A file belonging to the 'xxxx_port_name' port is missing or unreadable. Consider reinstalling it.

这说明这个已经安装的包（xxxx_port_name）有文件挂了。这时候直接install 和 update，不能解决这个问题，最好强制re-build一下：

1.sudo port -n update --force xxxx_port_name

至此，准备工作已经完成了。

Let’s do it!

FM收音机工作原理

注意哦，这里是FM收音机工作原理，不是FM工作原理。FM的原理自己回去翻通原去吧。大体上，一个简单的FM收音机是这个样子的：

这几个部分的工作流程是这样的：

RF电路把中心频点调到某个频率，天线接收信号
对接收到的模拟信号进行ADC，采用频率为
将ADC后的数字信号经过一个数字低通滤波器，剃掉一些没有用的高频噪声。
滤波器输出信号按照FM进行解调
将解调后的数字信号转换成适当的电平通过扬声器播放

大致了解了FM收音机工作原理和工作流程后，我们就可以开工了。

啊？这就开工了？

接上电源，打开电脑，找到苍老师……XD，瞬间小岳岳附体了。

接下来请出我们的主角。

GNU Radio Companion

GNU Radio 提供了一套可视化的搭建平台，这既是GNU Radio Companion（以下简称GRC）。如果你以前接触过Matlab的Simulink，你会发现GRC已经把搭建系统这件事情，简化到了“傻瓜级”的水平。从GRC的角度看，基本操作就4个：

选择需要的功能模块
根据设计配置模块参数
把模块连起来
不满意？用自己写的模块啊(out-of-tree modules)

怎么样，简单吧？在这里，我就不给GRC做广告了，只额外再多说两句：SDR是engineering + coding 的结合。一方面，攻城狮们在通信原理、DSP、还有电路硬件方面的知识构成了任何一个SDR系统的backbone；另一方面，程序猿们的优化和扩展则是SDR的精髓，是真正让SDR与众不同的灵魂。

不扯这些，现在我们还是小学生，先学走路。

模块及参数配置

用MacPort 安装了GNURadio之后，就默认安装了GRC。不需要额外的配置，直接就可以用：

1.gnuradio-companion

GRC的默认界面是这个样子的（我这边MacPort提供的GRC版本使用的GUI是基于QT的）：

模块的基本操作简答提一下：

添加模块：从右边的列表里选中需要的模块，拖到左边的空白处；
配置参数：在模块上双击或者右键点Properties。一般都会有Documentation Tab，没事儿多看看。
链接：单击模块a的输出(out)，再单击另模块b的输入(in)，就会自动完成把模块a的输出数据作为输入送入模块b的操作。而对于变量，可以通过”Variable”模块或者GUI输入的各种输入模块进行变量ID声明和变量赋值，在其他模块中利用变量ID名进行引用。
取值：可以直接输入值、引用变量ID，也可以是python运算表达式。
简单调试：如果框图中有错误，Error按钮就会变亮，点击后可以看到模块级的出错信息。
其他操作：看右键菜单。

RTL-SDR Source

RTL-SDR Source是RTL-SDR USB dongle的驱动接口，通过它我们可以完成对信号接收和ADC（前面提到到步骤1 和 2），还可以配置增益控制。

参数配置很直白，就不一一介绍了，拣几个重要的说：
Sample Rate：我用的RTL2382U理论上最高支持3.5Msps的采样率，但是无损的采样率最高为2.56Msps。采样率过低会导致最后音频解调失真，但是过高又会造成处理速度下降。因为FM Radio有效的带宽也就撑死了100kHz，所以这个数值我设在1-2Msps之间，例子中是1.28e6sps。
Ch0: Frequency：中心频点的位置。如果我们打算收听帝都交通台FM1039就调到103.9e6
Ch0: Freq.Corr：设备的频偏修正。在前一篇文章在测量GSM基站频点的时候，测过我这套RTL2382U+R820T的频偏修正大约为-28ppm。每套设备修正值都不同，但是对于FM收音来说，偏个几十KHz都没问题，所以0也可以。

在这个部分，我用变量samp_rate来设置采样率；用一个QT GUI中滑块来动态调整中心频率，实现调台（Turn！Turn！Turn！）

LPF

低通滤波器。基带信号有用的就那1-200kHz带宽有意义，因此在采样后利用LPF把高频信号全都滤掉。核心参数有两个：Cutoff Freq和Transition Width。两个参数的含义看了下面这俩图你就明白了。

因为我们并不知道广播电台FM信号的带宽具体是多少，所以用一个滑块来调节Cutoff Freq，从1kHz到200kHz步长1kHz。数字低通可以令LPF的边缘非常陡峭，代价就是引入一些毛刺，因此对Transition Width也做了一个滑块，用来控制LPF的形态。

你大概发现了，还有个Decimation咋没提呢？这里先留下，后面单独介绍。

WBFM

WBFM是WideBand FM模块，对应的还有一个NarrowBand FM（NBFM）。WBFM模块有两个参数需要配置：

Quadrature Rate：采用正交解调方法，我理解Quadrature Rate就是I/Q支路上的符号速率，这里我们设置为320e3(320k)
Audio Decimation：和前面Decimation一样，最后再说。

Rational Resampler

顾名思义，这个模块的功能就是数据流的速率。在这里顺带手吧前面一直说的Decimation来解释一下。

数据流的速率

所有的Block都有一个输入，很多（但不是所有）Block也都有一个输出。输入数据流的速率可以理解为函数传递参数的个数，例如，有的是320k（320e3）个，有的是2M（2e6）个。如果模块A的输入数据流的速度是，输出的数据流的速率是，模块A要把这个数据流作为输入送入模块B，那么至少要保证的个数与模块B中定义的输入数据流的速率是一样的。换句话说，我们要使模块A的输入数据流的速率，在经过模块A处理变成速率为的输出数据流时，满足。

为了达到这个目的，最直接的方法就是在模块A上定义一组系数和，在模块A上对输入数据序列进行抽取，使速率下降为原来的，之后再用内插数据点的方式，使输出的数据速率增加到倍。这么说可能有点别扭，用公式表示就简单了：

就比如我们这个框图吧：

WBFM输出的数据流的速率是320K，这个数据流作为Rational Resampler的输入，即
如果我们希望经过Resampler之后的输出数据速率变为32K，那么就可以设置Decimation为10()，设置Interpolation为1()，这样输出的速率就变成：

前面几个模块中的Decimation也是这个意思，依此类推。

数据类型

这是一个没有显性说明的因素，在我们这个例子中：RTL-SDR Source只提供Complex（32bit）的输出；LPF、Rational Resampler支持Complex和Float，但是输入输出数据类型要相同；WBFM Recieve没有任何选项，但是实际上他要求输入必须是Complex，输出是Float。

从写程序传递参数的角度看，不同的数据类型占用的存储空间是不同的：一个Complex包含实部和虚部，因此至少是两个Float。因此在不同的模块之间传递的数据流，不仅仅要个数匹配（数据流的速率），数据的长度也要匹配（数据的个数 *每个数据的长度）。这点在配置的时候要注意。

现在你可以思考的问题是：为什么WBFM模块在做FM解调的时候，输入输出为什么一定是从Complex类型到Float类型呢？Hints：WBFM把复信号解调成实信号输出。

Audio Sink

这个模块的作用是把数字信号转成模拟信号通过声卡播放出来。类似前面RTL-SDR Source中的采样率，这里需要一个采样率来进行DAC。

效果

除了上面提到的几个模块，我在LPF后面接了一个示波器；在Audio Sink前接了一个乘法运算模块和滑块作为音量调节。你也可以不加这两个模块。最后，把所有模块连接起来，整体的流程图是这个样子：

运行

通过调节Freq滑块进行频率调整，找到你想要收听的广播电台。调节LPF的两个滑块调节LPF的Cutoff和Transition宽度，调整送入WBFM的FM信号带宽，从而改变最后的解调出来的声音效果。

d(˙v˙)b

Enjoy!

启动 Fuseki 服务

启动Fuseki服务

Apache Jena Fuseki 是一个服务器，而并不是一个在Tomcat上跑的程序。因此，在本地启Fuseki的时候，和启动Tomcat服务器的方法相似，直接运行启动程序就好了。不过我还不知道怎么关闭Fuseki。

启动 Fuseki

首先需要下载Fuseki，从官网获取下载地址，并下载apache-jena-fuseki。

接下来，我们把下载下来的压缩包解压到你放tomcat的地方。我一般将这些自己装的东西放在/usr/local/下面：

/usr/local/apache-jena-fuseki-2.3.0

接下来，我一般会在.bash_profile中声明一下路径，这样可以避免一些不必要的麻烦。在~/.bash_profile中加上：

# Settings for running fuseki
export PATH="/usr/local/apache-jena-fuseki-2.3.0/bin:$PATH"

注意到，我并没有把启动fuseki服务的脚本所在的路径添加进去，这是由于这个服务对我来说，并不会经常用到。

之后，进入/usr/local/apache-jena-fuseki-2.3.0，就可以输入如下命令启动fuseki了。需要注意的是，启动服务需要root权限。

sudo ./fuseki-server --update --mem /ds

如果一切顺利，fuseki服务的log会显示出来，比如下面这些：

[2015-12-10 12:20:34] Server     INFO  Dataset: in-memory
[2015-12-10 12:20:34] Server     INFO  Fuseki 2.3.0 2015-07-25T17:11:28+0000
[2015-12-10 12:20:34] Config     INFO  FUSEKI_HOME=/usr/local/apache-jena-fuseki-2.3.0
[2015-12-10 12:20:34] Config     INFO  FUSEKI_BASE=/usr/local/apache-jena-fuseki-2.3.0/run
[2015-12-10 12:20:34] Servlet    INFO  Initializing Shiro environment
[2015-12-10 12:20:34] Config     INFO  Shiro file: file:///usr/local/apache-jena-fuseki-2.3.0/run/shiro.ini
[2015-12-10 12:20:34] Config     INFO  Template file: templates/config-mem
[2015-12-10 12:20:36] Config     INFO  Register: /ds
[2015-12-10 12:20:36] Server     INFO  Started 2015/12/10 12:20:36 CST on port 3030

此时 fuseki服务器就已经启动了。在浏览器中访问：

http://localhost:3030/

就可以打开fuseki的gui进行操作了。

动手玩：OSX下配置基于RTL的SDR

背景

SDR

Softwear Defined Radio（软件无线电）并不是一个全新的概念，摘句百度百科上通俗的概括：“软件无线电利用现代化软件来操纵、控制传统的“纯硬件电路”的无线通信技术。其重要价值在于：传统的硬件无线电通信设备只是作为无线通信的基本平台，而许多的通信功能则是由软件来实现，打破了有史以来设备的通信功能的实现仅仅依赖于硬件发展的格局。软件无线电技术的出现是通信领域继固定通信到移动通信，模拟通信到数字通信之后第三次革命。” SDR是不是数字通信革命的方向，会不会带来深远的影响，这些并不是这次讨论的主题（一家之言也没有什么意义）。这次，我们只把目光放在眼前，从兴趣出发，该怎么调戏SDR呢？

提问时间：RTL是个什么鬼？

“RTL”或者“RTL-SDR”是一个统称，泛指基于Realtek RTL2932U芯片的数字电视接收机（也就是俗称的电视棒）。这套设备除了包含了一整套可用于开发SDR的硬件（射频调谐器、ADC、USB界面），最大的特点就是“便宜”。在某宝上，算上天线，一整套设备下来也就几十人刀。再加上相关软件基本都是开源，也就是说，基本上一顿饭钱，就可以开搞了。

必须要说明的是：这套设备只含接收机，不能发射信号（能发射的话，估计就离被请去喝茶不远了 XD）

相比开源SDR中的另外两位重量级全功能（带收发,FPGA）选手：动辄几K美刀的USRP、虽说便宜但是也一二百美刀的HackRF，RTL以其实用的功能、相当于白送的价格，以及几乎完全没有法律风险，成为了入门或者廉价SDR的代名词。

关于RTL-SDR怎么被兴起的，先来个大家喜闻乐见的说书版本：“一天某大牛买了这款电视棒，想在linux下看看动作片，然而官方只有Windows版本的驱动，心急火燎的他便开始着手编写linux下的电视棒驱动，过程中发现这款电视棒允许原始I/O采样的传输，可用于DAB/DAB+/FM解调。于是他拉起裤子，开始了进一步的研究…”+。本着严谨的态度，这里再补个半官方（因为开源，压根儿就没有官方）的说法++：RTL2382U芯片组和相关产本的设计初衷本来就是用来实现SDR，只不过在发布的时候是和闭源的应用捆绑在一起（Windows版本嘛），所以各种牛比的潜能都算是被雪藏了在相对简单的DVB+ 以及FM应用程序里面了。这一切直到Eric Fry（就是上文提到那个火急火燎的大牛同学）通过嗅探USB接口上的数据包，发现了RTL2382U的潜力：这家伙直接吐IQ支路数据流啊！于是Eric开始着手写RTL2382U的Linux驱动，算是点燃了第一支火把，后来Realtek公司也陆续放出了一些alpha版的Linux软件（FM、DVB什么的），然后生产E4000系列协调器（最高可以扫到2.2GHz频段的廉价神器，国内LTE频段自然没问题啦）和配套SDR产品的Osmocom公司、各种大牛也陆续搀和进来，然后Boooom，RTL-SDR火了！

关于OSX

那么，关OSX什么鸟事儿呢？这……因为我用的是苹果。（别打，别打）其实，比较现实的原因是，现有的关于RTL开源软件的开发、配置和使用绝大多数都是针对*niux。虽然苹果也算是准Linux，但是，从开发的角度看，各种库的使用是有差别的，这就造成了在Linux下行得通，在OSX下就不能简单的“如法炮制”了，需要自己tweak。

硬件配置

首先，请出我们的主角：寨都产电视棒（居然还有牌子：德国坦克）+2.5dB天线套装+ MCX-SMA转接器：

转接器还是必须得，市面上的天线普遍都是SMA接口的，而电视棒一般是MCX接口，所以，为了能换天线，这个东西最好还是来一个。

接起来是这个样子。天线下面带有磁铁，方便室外固定，不过在桌子上，还是请来个扶天线的助理吧。

硬件部分就完成了，simple吧。接下来开始搞软件部分的配置。

实验项目

SDR，软件几乎决定了一切功能。那么这次实验做点儿啥呢?FM收音？适合给通原当实验，以后有时间可以温习一下；DVB-T太欢乐了；Tracking airplane？不错，不过这个留给以后专门介绍ADS-B系统时候用吧；GSM信号分析…..分析可以，cracking可不行，原因你懂的（算了，还是郑重声明一下：破解不属于你的GSM信号是一种严重的违法行为，这里也不会涉及这方面的内容，也再一次郑重地劝你不要尝试，后果自负）。通过GSM信号分析，可以看看GSM频带的频谱长啥样，在空口抓个包，新鲜新鲜，貌似难度适中，也挺能说明SDR的能力，就它了！

GSM广播信号抓取和处理

实验所需的软件清单如下：

1.Kalibrate:用来找GSM基站并校准； 2.gqrx:手工调整、确定RTL的工作频点； 3.gr-gsm：基带数据就靠它解码了 4.wireshark：数据包成形和分析

你也许会好奇，GNURadio呢？这个马上就会说到。

先说句题外话，OSX是一套很好用的系统，好用体现在集成度非常高，日常用得到的，基本上苹果都给你想到了，连开发这种很detail的事情，也大包大揽，给你准备好了。往好处想，一般来说，80%甚至更高的需求都满足了，东西拿来就能用，妥妥地生产力工具。但是剩下的那20%，特别是编译开源软件这块儿，那可就要费点儿周折了。但是，好在天无绝人之路，找到了门路，想解决还是可能的。

好了，说具体的，step-by-step。

软件安装

我们首先需要的是macport（https://www.macports.org），有了它，刚才提到的20%的困难中，90%的问题都可以迎刃而解。先别随便调高难度想全都自己来，留点体力解决剩下的问题。也别问我是怎么知道这些的，那全是不堪回首地血泪史啊T_T。 macport是一个包理器，类似于linux下的apt，只要是macport库里面有的软件包，它可以自动帮你解决掉各种依存关系和问题，版本升级也顺带手全解决了。需要了解的命令就两条：

看看macport的库里有没有PACKAGENAME这个包：

port search PACKAGENAME

装：

port install PACKAGENAME

通过macport安装的最重要的软件就是gqrx。

port install gqrx

因为根据依存关系，在安装gqrx的时候，会把GNURadio以及RTL驱动等等各种乱七八糟的玩意儿全搞定，一句话全部搞定多省事儿。还是那句话：这块儿别自己瞎折腾，万里长征第一步，别刚出门就把脚崴了。这时候，你可以去喝杯咖啡，或者看个书啥的，因为需要安装、编译很多很多软件，gqrx的安装过程可能需要持续将近1小时（基于13-Late MBP，要是更老的Macbook，时间更久），注意，别把自家网络带宽耗尽，安装过程需要下载的。

安装完成后，Launchpad中应该增加了一组东西,接上RTL-SDR和天线，启动gqrx，我们已经可以做一些事情了，例如看看功率谱，听听收音机什么的。

我们暂且把注意力拉回来，继续搞其他软件。gqrx的安装过程看似极其简单，实乃拜macport所赐。但是macport高度自动化的代价就是和系统配置存在冲突。由于OSX本身已经预装了python，而在macport里面根据依存关系，在安装GNURadio德国程中也会安装python2.7，用此macport会把自己的python安装到 /opt/local目录下面。

这时相当于同时存在两个python环境，一套是在/usr/bin，对应的库在/usr/local下面；另一套全在/opt/local下面，这两套python环境之间是默认情况下是独立的。（这也是macport设计的初衷：自成体系，既保护系统也稀释自身也不受系统约束）。

这一点区别在编译连接的过程中至关重要：要想在编译中使用macport提供的软件包，必须要用macport的python环境。而在默认情况下，使用的却是系统的python环境。

如果所有的软件都有如gqrx一般，能够通过macport来搞，问题就简单了。遗憾的事，no way。在更加广阔的开源世界里，还要靠我们自己丰衣足食。不过有了上面这个基本认识，接下来的工作就相对容易理解了。

安装kalibrate

首先到Github上clone下来kalibrate的源码。如果你用的是Linux，可以从https://github.com/steve-m/kalibrate-rtl.git上获取：

git clone https://github.com/steve-m/kalibrate-rtl.git

如果你用的是OSX，建议从我的这个源下载，里面去掉了OSX没有的库，这样在编译连接的时候，不会报错。

git clone https://github.com/zhao414/kalibrate-rtl.git

编译安装过程：

cd kalibrate-rtl

mkdir build

./bootstrap

cd build

../configure

make && sudo make install

安装完成后，可执行文件在/usr/local/bin下。如果你想安装在别处可通过如下方式安装到/YOUR/PATH/bin目录下

../configure --prefix=/YOUR/PATH

安装完成后，试一下：

$ kal error: must enter channel or frequency kalibrate v0.4.1-rtl, Copyright (c) 2010, Joshua Lackey modified for use with rtl-sdr devices, Copyright (c) 2012, Steve Markgraf Usage: GSM Base Station Scan: kal <-s band indicator> [options] Clock Offset Calculation: kal <-f frequency | -c channel> [options] Where options are: -s band to scan (GSM850, GSM-R, GSM900, EGSM, DCS, PCS) -f frequency of nearby GSM base station -c channel of nearby GSM base station -b band indicator (GSM850, GSM-R, GSM900, EGSM, DCS, PCS) -g gain in dB -d rtl-sdr device index -e initial frequency error in ppm -v verbose -D enable debug messages -h help

出现kal的帮助信息就算OK了。

GR-GSM的安装

接下来要安装的是GSM信号的基带解调软件。在这个部分，我们其实有两个选择：

1.Air-Probe

2.GR-GSM

Air-Probe是最早提供GSM基带信号解调译码的工具，有年头了。从Github上的更新来看，上次更新还是在2013年。老不代表不能用，只是兼容性可能不太好，我反正是尝试了N多种方法，尝试了很多种配置方法，最后还是没有在OSX下跑起来，遂放弃。如果想要尝试，请自行放狗，满大街都是。

GR-GSM是目前仍然活跃的开源项目，上次更新是在2015年9月，目前支持USRP，HackRF以及RTL。默认支持GNURadio 3.6，加了补丁可以支持到3.7（也就是说，使用3.7也可以编译通过）。所以这里我们就用它了。

我安装GR-GSM的过程是很曲折和漫长的，当然，你就不用走那么多弯路了，step-by-step。

首先是准备工作：更新系统的G

接下来安装libosmocore。下载libosmocore。

git clone git.osmocom.org/libosmocore.git

安装过程：

cd libosmocore aclocal autoheader autoconf glibtoolize mkdir build cd build ../configure make && sudo make install

为了简化配置过程，下载这个use_macports.sh：

git clone https://gist.github.com/34b4bec84c3eeb2bcc8e.git cd 34b4bec84c3eeb2bcc8e chmod +x use_macports.sh sudo mv use_macports.sh /usr/bin/use_macports cd .. && rm -r 34b4bec84c3eeb2bcc8e

墙内https访问如果有困难，可以直接到网页上去copy。然后，就可以安装GR-GSM了。

git clone https://github.com/ptrkrysik/gr-gsm.git cd gr-gsm mkdir build && cd build use_macports cmake .. ./configure make && sudo make install

接上RTL，输入如下命令：

airprobe_rtlsdr.py

能正常运行，GR-GSM就装好了。

安装wireshark

这个部分最简单，标准的osx软件安装过程，软件从wireshark官网下载（dmg文件），安装好后，按照运行时的说明，（如果需要）下载安装XQuartz就完事儿了，和前面的比起来，毫无难度。

一些安装编译过程的补完

虽然自己编译的软件放在/opt/local比放在/usr/local更合理一些，为了运行时减少出错的概率，有洁癖的同学还是放弃/opt/local吧，搁在/usr/local会省掉很多很多很多解决稀奇古怪问题的时间；
如果make的过程中编译错误，请用新版的GCC（如5.2.0）。装个软件还要先更新系统的GCC，感觉好像挖了OSX大厦的地基一样有没有！？其实这一步早就应该做，原因很简单：新版的GCC支持（认识）C++ V11 or later中的很多new features。之所以叫New Feature，是因为在以前的C++版本（或者说老的GCC）中，编译器可是会把这些feature当做问题来看待，会导致很“堂而皇之”的error和warning，也就是你看着error log觉得：GCC说得对啊，这个代码怎么可以这么写，作者脑袋进水了吗？然后查了新的标准之后，发现其实SB的是自己，带着一脑子文物级的知识用着一个古董编译器还觉得挺美。更新GCC的过程请按照这里来进行,大约需要20-40分钟，约2G硬盘。
关于cmake，对于要使用cmake编译的软件，一个非常好的习惯是建个build目录，并按照gr-gsm部分介绍的方法运行cmake，因为（至少）在编译器配置的部分，cmake是一锤子买卖，第一次运行时加了参数，就配死了，改不了（看起来可以，实际不起作用）。因此，用build目录，如果cmake配错了，直接删掉整个build目录，再重建一个就可以重配了。

进行实验

最喜欢这个部分了，因为有很多可看的。

首先用Kalibrate来扫GSM基站的频点、频偏和时钟误差。

kal -s 900

由于我的硬件只支持到1.7GHz，所以只需要扫900MHz左右的频点就够了。

$ kal -s 900 Found 1 device(s): 0: Generic RTL2832U OEM Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner Exact sample rate is: 270833.002142 Hz [R82XX] PLL not locked! kal: Scanning for GSM-900 base stations. GSM-900: chan: 23 (939.6MHz + 25.439kHz) power: 772914.49 chan: 33 (941.6MHz + 25.679kHz) power: 489086.24 chan: 93 (953.6MHz + 24.714kHz) power: 159716.51 chan: 107 (956.4MHz + 25.206kHz) power: 273868.08 chan: 110 (957.0MHz + 24.866kHz) power: 252722.96

可以看出信道23的功率最强。我们就挑这个信道了。接下来，测量一下信道23的频偏和时钟offset。

$ kal -c 23 Found 1 device(s): 0: Generic RTL2832U OEM Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner Exact sample rate is: 270833.002142 Hz [R82XX] PLL not locked! kal: Calculating clock frequency offset. Using GSM-900 channel 23 (939.6MHz) average [min, max] (range, stddev) + 28.099kHz [28042, 28147] (105, 28.366884) overruns: 0 not found: 5 average absolute error: -29.905 ppm

接下来，用gqrx看一下GSM信号，也是为了确认一下频偏。

一个需要说明的地方就是，其实，信号强的地方GSM的信号频谱可以是这样的：

今天测试的地方比较背，所以将就啦。可以看到实际（显示）的频点位置大约在240.6MHz，大约比信道23的理论值偏差了1MHz左右。这可能是RTL硬件的误差。Whatever，接下来的工作以这个为基础进行。

打开GR-GSM

airprobe_rtlsdr

在GUI里，按照刚才获得的频点、ppm进行调整。这时，在终端中已经可以看到有数据源源不断地解出来了。

这时，打开wireshark，监听localhost端口的GSMTAP标签的数据，就可以看到包信息了。

至此，实验结束。

其他有趣的项目

SDR还有很多其他有趣的开源项目，除了前面提到的收音机、tracking 航班，还有一堆好玩儿的东西，这里截个部分项目的列表，就不一一介绍了，感兴趣的童鞋请参考这里或这里。

除此之外，还有三个关于RTL-SDR的大站可以供学习参考：

2016-Nov-11

后记：

本文作为原始稿件，准备出版时，编辑语重心长地写下了如下的修改意见：

请商量一下：这部分内容实在是太口语化了，而且出现了很多禁用的语言，还涉及告诉读者如何盗版、如何翻墙的东西，总编签字的时候要看到这部分，肯定这一本书就不让出版了。大话是本书特色，但还请尽量少用网络用语、少用口语，尽量用通而不俗的语言，若作者坚持还要放这部分内容在书中，请好好改一下，编辑只看完了第一个动手玩，把一些感觉有问题的句子和太过于口语化的语言批注出来了，请好好修改一下，不要只把批注出来的东西删掉，多谢！

看到之后，非常开心，因为标红的那几个地方，确实是我写这篇稿子时候非常想要达到的状态，看来编辑同志已经心（nei）领（xin）神（beng）会（kui）了，哈哈哈。

虽然最讨厌假模假式，但是，“通而不俗”确实是值得挑战和玩味的部分，要好好修改。

2018年四月
一	二	三	四	五	六	日
« 3月
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30