老邵的开源世界

我这边也没有停下脚步，我也在KerberosSDR的基础上做了改进，并把改进后的产品取名为“无线电罗盘”。你的测向频率不一定要完全匹配天线上标出的330MHz 495MHz 990MHz，只需要根据实际要测的频率选择合适的孔位，然后直接把孔位间距（10cm, 20cm, 30cm）输入测向软件中即可。近两年，国外团队基于KerberosSDR做了一些改进，加入了自动校准，增加了通道数，软件上加了极坐标显示，并做了远程汇总测向结果功能，并取名为KrakenSDR。上图就是我的无线电罗盘的整套测向系统。

我找了kerberossdr的2832的1.2v引脚没有用独立的电源供电。而是直接用了2832自己的3.3v pwm输出，然后用阻容转换为1.2v直流。类似开关电源的原理。3.USB附近的EMI频谱其实跟上图2832附近的也是差不多的。我还探测了噪声源附近，如果开启以后，反而是在0Hz附近会有底噪抬升，这个有点出乎意料，按我的想法应该是全频段底噪抬升。因此共享的EMI干扰不大，这一点也可以用近场探头验证（未拍照）。上图就是这颗共享的时钟，我测了它的几个引脚，有5V供电，说明它是有源晶振。

我还测过FM调制了。也能看到调制度降低后，频率变化范围会减小。但是我的示波器只有频谱图，没有瀑布图，所以无法准确了解FM调制的基带波形到底是怎么样，只能通过波峰左右晃动大概看看。可以看出时基最小的时候看到的都是正弦波，这是载波。时基大了以后看到的才是包络，而这种包络与日常看到的随机噪声很像。加完调制深度后，我还测了锯齿波，也没有昨天变成三角波的问题了。不过今天用的设备里的hackrf是r8，昨天是r9。昨天说了还差一个调制深度要加。时基100ns/div。

我们给它加一个带通，再用ADC采样，有可能恢复出一个比较低频的正弦波，我们只要把这个低频正弦波的频率再加上fs/2，作为新的频率，就可以完美复原出这个正弦波了。如果原本的信号不是单音的正弦波，而是一个宽带信号，一部分在Zone I，另一部分在Zone II，那么它自己的两部分可能跟自己混在一起，也没法用一个滤波器把它们区分开，就没法用。如果我们事先知道真实信号的频点，只要把它对应的奈奎斯特区域左侧的频率值加上采样后的低频信号的频率，就能恢复出原始信号了。因为ADC的采样信号，在时域上是一个脉冲串。

即使0Hz处是存在尖峰的，但也会被滤波器过滤，你在最终的频谱上看不到这个尖峰。先把中心频率故意设置在偏离目标信号的频点上，然后用cosine函数，把目标信号下变频到0Hz，而把原本的0Hz变到滤波器带宽以外。相信大家第一次打开gnuradio看听广播、看频谱的时候，会注意到一个奇怪的现象，明明在频谱中间不该有信号，但是实际看到了一个尖峰。在rtlsdr的书里也有介绍。不但SDR会这样，如果用示波器打开FFT功能，你会发现在最左侧0Hz附近也会有尖峰（示波器FFT默认频谱左右对称，不显示0Hz以下的部分）。

所以，上面这些就解释了，如果你要用简单混频器，那么就不能直接变到0Hz附近的基带，而是搬得稍微高一点，比如对于rtlsdr来说就是3~5MHz就没问题。公式推导证明了，在输出端可以得到下变频后的S(t)，它的载波从w2变为了wIF，并且输出端的信号可以只有我们要的S(t)，而与R(t)无关。但如果要设计的SDR要支持更高带宽的信号，它的中频就必须更高，我们的ADC采样率不够采这么高的中频，我们就必须考虑其它方案。2.用正交混频，也就是先分为两路，一路用余弦，另一路用正弦，分别采样，其中一路移相后再叠加。

只有CW时，可以看到中间有个尖峰，如果用示波器时域测量，能测出频率是100MHz附近。尖峰旁边有一些小尖峰是因为hackrf硬件的SFDR不好，产生的杂散，由于它们无法由软件控制，后面请尽量忽略这些杂散。你可以自己选择各种基带信号，比如方波、三角波等，但是这些信号都必须经过FM调制后发射出去。接下来发正弦波，这时候你会看到，包络在变化，类似正弦波，并且频谱上除了中间载波的波峰外，还左右对称出现两条尖峰，这就对应了正弦波的基带信号。上图是方波，看着比较正常，可以用光标测出基波也是500Hz。

4.无线电罗盘接入usb协会的xhsett软件后会出现很多个设备，我猜测应该分别是hub芯片对外的接口，4个rtlsdr，1个cp2102芯片。但是downstream的几个rtlsdr就没法测了，这个应该是因为测试方法导致的，不是设备不过关，不然哪怕看不到眼图至少也应该能看到波形。2.自制的RTL-SDR的波形也能触发成功，但波形恶化较为严重，无法叠加出眼图，可能因为没有控制好USB阻抗。上面几个0xbda应该都是rtlsdr的rtl2832u芯片，但是虽然也能进入测试模式，但无法看眼图。

之前我用专业仪表测过portapack在内置电池口上的打开不同APP的功耗。这次我想用另一个设备测一下USB口上的功耗。对比一下看看几款不同SDR的耗电情况怎样。还可以比较Portapack使用同样功能时，在USB和内置电池口上耗电有什么区别。以下是Portapack打开NFM解调的功耗，此时没有打开喇叭（5.07V 0.427A 2.16W）：同样是这种状态， 之前在内置电池口供电是4V 0.532mA 2.128W。可以看出来功耗是差不多的，USB供电时稍微大了一些可能是因为最新H3上的GPS接收芯片的

上一篇文章留下了一个问题，就是如何解决垂直线变斜的问题。这个问题本来应该从通信上来解决，找出行同步信号，然后在这个信号处换行。但是实际并不好做，因为hdmi并不是无线通信标准，没有这方面的资料。因此，我打算用图像处理的方式来解决。即找出原始画面的规律，然后从画面上直观地做一些修改，来改善效果。我本来考虑过给图形做仿射变换，相当于旋转图像，但是我估计效果不会太好。后来我想了想，目前的问题无非就是每个行开始处有个offset的问题。我只要把这个offset位置的像素点挪到最开头那个点就行。还有个问题是这个off

接下来我们开始优化画面首先我改了换行位置，原本是463才换行，差不多一行重复出现8个重复画面。我把463/8得到58。在x>=58时换行，可以看到只剩一个画面了，但是画面宽度变窄，显得变形了。这时候我再对每行的像素点差值，大概每个像素点重复往右画10遍，就可以得到如下效果：可以看出现在画面放大了，基本上显示界面就对应了1个屏幕的泄漏画面。我的代码如下： 但是从画面看出来，整个屏幕还是斜的，本来白色矩形在我泄漏屏幕上应该垂直，但是现在是从右上往左下角倾斜的。这个问题也可以解决，需要把每一行的数据单独存下

第一篇文章我本打算用python写代码并使用rtlsdr来接收，这样不但代码简洁好懂，而且设备也非常便宜，很好入门。但是第二篇文章我为了尽早实现效果还是采用了c++语言和hackrf。可能会对入门者不太友好，所以这两天我继续做python+rtlsdr的版本。现在已经初有成效了以上是我的代码，一共才30多行，十分简介。可以用python2.7运行。当rtlsdr在hdmi线缆附近时，效果如下： 这是泄漏电脑的桌面：可以看得出他们是比较呼应的——总体界面都是黑色，上面都有一条白色横条，然后左边有一条垂直

我后来找到了gr-tempest包，它基于gnuradio重置了tempestsdr，由于是gnuradio，比较方便我本地安装，因此我跑了一下，结果没跑出实际效果，可能因为它默认用usrp，我这用的是hackrf+重采样，硬件不太一样导致的。但是它里面还有个simulate的流图，可以导入图片再重新解出来。这个我玩成功了，通过调试，我发现在不同sample correction时，会出现类似第一篇文章的样子，也会出现比较像样的画面。所以我的信心大增。后来我还是决定在我以前的c++/hackrf实现的模拟视

之前听说有个神奇的软件叫做tempestsdr，可以用sdr来接收显示器泄露出来的信号。这个软件说实话很难安装，因为是java的，并且只给了代码。但是我看了他的代码其实核心就是AM解调，因此我有了自己写代码来实现这个功能的想法。tempestsdr的名字其实不是随便起的，tempest是Temporary emanation and spurious transmission的缩写，专指这种类型的泄漏。我用了另一个知名软件TVSharp也大致看到了HDMI泄漏的信号，进一步验证了我的想法，就是用AM解调并把

最近芯片惊魂比较多，从一开始的芯片涨价，到现在好多芯片买不到。芯片涨价还能咬咬牙继续做，只要采购成本低于重新设计和打样成本就行。买不到芯片才是最坑的，直接被逼无法生产。如果是模拟芯片还好，只改电路，如果数字芯片还牵涉改一堆软件，头疼。HackRF最近应该也是碰到了类似的问题。一位朋友跟我说BOM里改了个零件型号。最新版本的BOM里几个sky13350替换为了sky13453，并且把PCB丝印改为2021版了。我查了github，发现固件和驱动都有修改。顿时慌了，难道新版本固件和驱动要放弃老款了？那我的P

最近因为某些原因，需要重装ubuntu，然后kicad也要重装，有版本兼容问题，也有导入自定义库的问题。在这里作个记录。原版本：Ubuntu 16.04 KiCAD 5.1。新系统是Ubuntu 18.04，默认安装的是KiCAD4.0，显然太老了，打不开5.1的项目文件。而KiCAD网站上的PPA也只提供了6.0的。Install on Ubuntu | KiCad EDA我仿照那个网站的命令，稍微改了一下版本号。sudo add-apt-repository --yes ppa:k

就跟以前windows98还有后来的安卓手机一样，这些带智能系统的设备用久了都会问题越来越多。iPhone虽然不容易越用越卡，但是存储空间还是会越来越少，直到系统频繁提示，如果一直不予理会整个系统都会崩溃。（我用下来大概只有ubuntu不会有这类问题，至少不会平白无故用出问题来，只要别make install一大堆重复的程序就行。）我的iphone最近就出现了这样的问题，常见的招数我都试过了，把相册里的照片视频删光，把大型游戏删掉，后来我还把整个微信APP都删掉了，还是不行。每隔一段时间iPhone存储

上一篇文章实现了测向，也尝试了定向录音的效果。虽然定向录音是有效果的，但是好像目标方向不太稳定。后来我找到如下文章，它说要在sst里把dynamic改为static，并且指定好方向坐标。# Configuration file for ReSpeaker USB 4 Mic Array (ReSpeaker USB Mic Array v2.0)version = "2.1";# Rawraw: { fS .

上一篇文章说到odas_web界面非常难安装，并且运行也很卡。所以我自己用python写了一个界面程序，用来接收odas处理完的结果。这个界面程序与odas之间是通过socket连接的， 界面作为服务器，odas作为客户端，由于有两路数据，所以各有两个服务器和客户端。但是实际绘制在界面上的是SSL的结果，不是SST的结果。其实我也试过SST的结果，从直观的感受而言，效果会比SSL差一些，实时性不是很高，我的理解SST的好处是可以跟踪音源是否有活动。

主要参考：在树莓派上实现ODAS+Windows远程web演示_jimaofu0494的博客-CSDN博客ReSpeaker Mic Array v2.0 - Seeed Wiki多年以前，我实现了16通道麦克风阵列，包括测向和波束成型。16通道麦克风阵列 声波成像 声源定位 波束成形 定向录音_哔哩哔哩_bilibili很多人问我要买，但是那套系统不方便批量生产和发送。所以我开始想办法做一套简化版系统，包含硬件和软件的简化。在用16通道麦克风阵列前，我其实还有2个usb的麦克风阵列