RC震荡电路学习笔记（7）
在《RC震荡电路学习笔记（6）》中，已经了解了电容中的电流与电压相位相差90°的原因，并且也知道了一个简单的RC电路可以形成电压信号的相移，此时按道理说，就可以通过3组RC相移器构造出的180°相移网络做出振荡器来了。 并且还是依据上一篇文章中最后得到的频率计算公式，可以计算出最终的频率应该是： 滞后器网络： 超前器网络： 然而事实上并不是上面这个计算得到的频率。上一篇文章中用于计算的只是“纯理论模型”，这个理论模型中的3组相移器是被假设成彼此孤立、不会相互影响的。然而实际电路并不是这种纯理想情况，实际电路中的三级相移器是彼此耦合在一起的，因而拿出任何一点考量，都会发现它并非单纯的RC电路，整个系统中的阻抗都会相互耦合作用到一起。 因而上一篇文章中的计算只是对RC相移网络的原理进行了解和讲解，并不能用于指导真实电路的设计和计算。 对于真实的电路，要使用传递函数进行分析，这个传递函数的定义是：，我使用M意思是测量量，这个具体的测量通常是电压，也就是输出点对输入点的电压比视为电路的信号传递能力。在三级RC相移网络中，不考虑RC网络前级、后级更复杂的情况，仅对这个相移网络进行分析的话，容易得出： 整个网络的信号传递 现在仅以第一级传递进行考量：因为第一级RC环路中的电流处处相等，因而输出点的电压就是R和C的分压。后面的第二级、第三级也都是这样的情况，所以可以根据传递函数得到如下的传递计算式：。 最终得到总的RC网络传递计算式： 因为考量的是输入点和输出点电压，而电压等于电流与阻抗分压的乘积，电流在每一个环路中显然又是处处相等、满足基尔霍夫电流定律的，因而这个传递式最终的表达式便变成了对电路中阻抗的分析。 如果按照上一篇文章中的理想模型来看，传递函数将写成：，这个模型不难求解，而且解出来的结果也是和上一篇文章最终得到的结论是一致的。 然而本篇文章已经明确了：在真实电路中由于各个IC的相互耦合引起了每一个考量点的阻抗的变化，因而上述传递函数最终变成了：。 也就是对于第一级、第二级的输出点位置上，并不是简单的串联点，而是与后级电路形成了并联关系。它的阻抗带入式是：。 看上去并不复杂，实际计算那是相当困难的。至少我经过了先后四次手算都没能得到最终的正确结果。现在感觉这个代数计算很困难，隐约觉得在复数工具中应该有比较便捷的计算方式，所以我便又重新开始看复数方面的知识，期望能够找到关于上式的计算工具。 总之，它的计算结果是：，此时为了方便后面的观察和分析，设 ，便可以将上述传递函数重新改写为：。 至此传递方程所能体现出的相移能力就显现出来了，因为这三组RC相移网络完成的恰是180°的相移，因而它的虚部等于0，也就是。这个虚部为0的物理客观，便构成了最终的结论。如此也就得到了真实电路（比上一篇理论电路真实、但依然是经过大幅度简化）的实际频率修正式。 但是注意到在更早之前的一篇笔记《RC振荡电路初学笔记（5）》中，对于实际的频率计算式还有更复杂的因素要考虑，当时我还在困惑是不是其中的哪一个频率计算式有错误，实际上两个计算式都是正确的，只是而一个式子是这篇文章已经得到了的，而那篇文章中的第二个计算式，显然是额外考虑了电路中其他的IC部分的耦合影响。 只是当前还没有学到。
RC震荡电路学习笔记（6）
一、之前的学习笔记整理： 学习笔记 内容简述及收获心得 RC振荡电路初学笔记（1） 关于Jack·Kilby发明集成电路，并且这个电路是RC相移震荡电路的引子 RC振荡电路初学笔记（2） 关于Jack·Kilby发明集成电路的历史趣闻 RC振荡电路初学笔记（3） 罗列了几点RC相移电路中的个人困惑和备忘 RC振荡电路初学笔记（4） 对Jack·Kilby为什么使用PNP而非NPN做震荡电路做了些毫无根据的猜测 RC振荡电路初学笔记（5） 通过仿真软件对RC电路具体参数确定时的正确输出频率做了仿真 RC相移震荡电路学习历史笔记列表 二、电容电流超前于电容电压的原因： 书上的解释是：只有对电容器充电之后，电容器内部有了电荷，电容器两端才有电压，所以流过电容器的电流是超前于电压的。如上的这个表述我是万分的无法理解和接受，电流和电压是同时产生的，怎么可能有谁超前、谁滞后的说法呢？ 在物理世界中，电压与电流应该就是彼此同时产生、同时消失的，不会有电流超前于电压的“预知”能力（如果特别特别较真儿、我觉得也应该是先有电压才能驱动产生电流，但他们二者的因果时序近乎于瞬时，所以不能用可评估的时间去表述谁先谁后。所以无论如何也没有道理说出电流超前于电压这种话来）。更准确的表述应该是：电容器上的电压变化率引起了电容器上的电流产生，而电容器上的电压波形与电流波形在同个坐标系上比较，是相同的正弦波形，但相差着90°的相位差。 以最简单的一个理想电容器举例，图样就是一颗电容器画在纸面上： 这个时候电容器内部无论带有多少电荷，它的电荷量都不会随着时间发生变化，因而电容器上不会产生电流。当外部向电容器输入电荷、或者电容器向外部输出电荷时，随着电荷的增加或减小，电容器上同时的表现出了电压的波动和电流的产生。 因为电容器的电流 所以电流的波动和电压的波动是同时因为电荷的增减而同时引起的。 而又依然是通过上式可以看出来：在外部存在一个正弦电压施压在电容器上时，电容电压的变化频率就是电源电压的变化频率，所以电容电压 电容电流 此时就能看出来电容上的电压与电流相差90°的关系来了。 额外的，还可以用另一个更简单的解释来说明二者存在着90°的相位差。依然是通过观察电容器的电流 。能够想到的是其中的电压V是个正弦波形态，那么在这个波形的极值点上的导数是0，所以这些极值点时对应的电流就是0，而在x轴过零交点上的导数最大（变化率最大），因而过零点时刻的电流最大。 上面这个关系说明了：电压最大时（正、负极值）、电流最小；电压最小（电压=0v）时的电容器充放电流最大。这与物理常识并不矛盾。电压最大时，在dt时间范围内电压却不再发生变化，所以没有电压的变化就没有电流；过零点虽然电容器上不存在电压，但是这个时候却是外界对它施压最大的时刻，最大的电压当然会获得最大的电流。…
開始在YouTube上面做視頻
十多年前的一位老同事找到我，和我聊了一陣子，并且問我有沒有時間做一些有關Java語言開發的視頻，以便幫助她的女兒學習Java語言。 我之前使用B站做過很久的視頻内容，但是因爲B站上面總會有各種各樣奇怪的人跑來我的視頻頻道給出污言穢語的惡意評論，所以我就對做視頻越來沒有興趣了。 這次老同事找我説過之後我，我想趁著這個事情，再做一些視頻，但是就不再發到B站，而是發到YouTube上面去好了。因爲同事人在國外、看YouTube應該要比看B站方便，我也就順便開始將自己的視頻更新到上面，一舉兩得。 做了很長一段時間的視頻，并不是爲了流量或關注人數，只是純粹自己的生活、學習、工作記錄，平日錄下來并且在找一個地方發上去，方便自己的朋友、家人觀看。選擇B站也是覺得這個網站的技術好、空間限制少，但是每每發出視頻就會有令人厭惡的評論，的確影響自己上傳的積極性。 發在YouTube上面其實也是有一些問題的，那就是我的親朋好友并不一定能去看，畢竟從國内訪問還是很困難的。但是我想YouTube上面發視頻也有好處：至少不會有那麽多的污言穢語。而且今後如果自己的親朋真的想我、想看我的視頻，相信他們也是可以看到的。 這麽想著，便開始給同事做她需要的視頻，等給同事的視頻做完之後，我估計自己也會養成上傳YouTube視頻的習慣，那時我便可以再將自己日常的生活、學習記錄，發上去。
微信小程序開發備忘
小程序開發已經用三脚貓功夫做了一些粗略的實現，接下來就是學習這個技術框架中的細節，并且返工之前粗略、粗糙的地方。今天學習了一下幾個技術技巧： 一、子控件向父控件發送帶參數事件消息 頁面上的button按鈕是我做的一個子控件、這個按鈕是放在panel控件中的。現在我想點擊button按鈕的時候，button按鈕完成響應、并將事件通知給panel，由panel接收並繼續處理事件。 此前的實現非常拙劣，就是只使用panel進行事件的處理： 這樣做的壞處是顯然的：觸摸會發生在整個panel中。而我希望的是觸摸僅由裏面的button受理。改造過程如下： 1、首先panel的頁面層，調整代碼如下： 這樣調整之後，panel不再接受bind:tap消息，而是會接收名爲customEvent的事件，一旦接收到customEvent事件，則進行running執行。此時的customEvent事件將由button發出，所以button的代碼寫成下面的形式： 這樣只要點擊了button，就會運行sendEvent方法，這個方法内實現向父層發出消息的過程，具體js代碼是： 通過triggerEvent發出了一個customEvent事件，父控件因爲綁定了這個事件、接收到並開始處理就可以了。 二、動態成員訪問的方法 類似如下的PHP代碼： 在JavaScript中的實現方式是： 三、控件數據初始化 微信小程序的components控件，似乎沒有（我不確定）如pages頁面那樣的onLoad()方法，儅加載了一個小控件之後，向這個控件中傳入一些初始變量，便沒有辦法找到一個Init()或onLoad()的地方，對這些傳進來的變量進行預處理、以被在頁面上使用。 此時可以使用控件的observers監聽服務，對傳遞進來的變量進行監控，一旦傳遞進來的變量生效，observers服務啓動，以便進行數據的預處理操作。具體代碼如下： 四、頁面中的if/else流控方式 此前頁面中一直是這麽寫： 現在有了更好的方法： 雖然在頁面上的if/else流控寫法我已經瞭解了，但感覺并不如C/C++那樣直觀，總感覺有些奇怪，擔心它的嵌套不準確。不過也不重要，總之今天掌握的，就是這些。
Android Studio开发应用在真机上安装运行
昨天在电脑上安装了一套Android Studio，这是一套非常高效边界的Android应用开发工具。初步使用觉得除了安装过程比较耗时，其它都很顺利。 以前从来没有接触过Java语言和Android应用开发，所以上手有一些缓慢，但网上例子很多，Android Studio本身也提供了初始应用程序框架，所以只需要新建一个项目就可以直接运行、观察结果。 我想将这个最基本的Demo运行在自己的手机上，也就是真机体验一下。看网上介绍都很繁琐，估计这些介绍都是基于低版本Android Studio而言吧？至少在我所安装的版本上，几乎不用做任何设计、不做任何额外的工作，很顺利就可以完成真机运行。 只需要两步：手机开启“开发者模式”、在AS内使用自带的包管理器安装USB Driver。如此两步中的第二步我也不确定是否是必须的，也许连USB Driver都不需要安装也说不定，总之我就只做了如上两步，并没有如其他文章列举的，又要升级驱动、又要安装额外的什么东西，什么都没有做，连上手机，就可以直接真机运行了。 然后我又看了看Kotlin语言，据说是比Java更先进、更优雅的语言。但是只大概看了一两眼，就觉得不喜欢。说实话我连Java都不喜欢，相对而言还是喜欢C/C++那样“板板正正”的语言风格，对于“如诗如画”的语言，你觉得它能够写出“自然语言感觉”，但在我看来这是一种凌乱与松散。 之所以要体验一下这个开发工具、以及上手接触一下Android应用开发，也不是有什么项目或开发任务，只是想在自己的手机里实现一些自己觉得比较有用的小工具。这些小工具在应用市场上其实很多，但不是收费、就是内置了广告，我觉得我既不需要太多的功能、也不想花钱或看广告。 所以自己实现一下，自给自足好了。
PHP8中不再提供XMLRPC模块
自从PHP8.0版本开始，php for windows的默认安装包里面已经不在提供php-xmlrpc模块。这是因为xmlrpc模块的编译依赖于libxml，也是一个古老且停止了更新维护的模块。也许是处于安全性和先进性的考虑，所以PHP8中的xmlrpc模块便也不再默认提供了。 但在官方文档中并没有明确的提出这一点，而是“暧昧”的说可以在pecl中找到相关的模块。在pecl的官网也的确能够看到这个xmlrpc的页面，其中也是模棱两可的继续展示着它的二进制下载地址。 不过它所提供的DLL二进制下载包的下载地址中所有的链接，都已经是无效的、无法完成下载的了。 不清楚这些预编译的dll文件，是曾经提供过、但后来某种原因不再继续进行编译、提供。以至于现在都无法下载；还是从PHP8发行之处，就已经不再提供。如果是后者，有一点很难解释：既然不提供、那么还发布这个页面做什么呢？如果是前者、也很难解释，页面上没有任何的变更提示声明。 无论如何，对于xmlrpc模块的使用，现阶段只有以下四个方案，并且也许只有第一个方案是可行的： 方案一、降配使用PHP7进行模块的使用； 方案二、在PHP8中使用networking-xmlrpc平替模块； 方案三、自己通过源代码进行PHP8扩展模块的编译，编译生成xmlrpc的dll文件使用； 方案四、自己使用simpleXML对需要的XML格式文件进行解析，完成相关功能。 我现在为了追求开发速度，临时使用了方案一，这样至少能让开发进度继续进行下去。不过这样一来，整个项目中的其他代码又会因为使用了PHP8的语言语法特性而无法正常运行。不大可能再对整个项目进行代码调整，所以这一方案只是临时的、仅仅用于完成xmlrpc相关功能部分的实现。 之后也许会考虑使用方案四重写现在的代码，自己实现其中具体的解析，这样就可以再将环境语言重新恢复回PHP8版，以确保整个项目依然能够正常运行。
SSH使用证书连接服务器提示String too long
路由器GL.iNet AR750S-EXT在前几天误操作变砖之后，重新使用UBOOT机制进行固件安装，并成功安装了Open WRT的最新版固件，此时此刻用着还算稳定。 不过在Open WRT系统内，预装的是Dropbear SSH的服务端和客户端，而并非Open SSH的服务端和客户端。 两个SSH的发行版本差别有一些，Dropbear SSH是专门针对嵌入式系统开发的，它对系统资源的占用更小，功能上也更加精简。虽说常用功能都一样，基本可以平替。然而事实上，对我而言他们二者还是有一定的区别，导致现在稍微有一些难以满足个人需求了。 当前遇到的最主要的问题是：直接使用证书访问登录远程服务器，DropbearSSH会提示String too long错误。 这是因为通常情况下远程服务器都是open ssh server，所生成的也就自然都是open ssh所使用的证书文件。如果直接使用dropbear ssh读入这个证书，会发现并不能正常读取： 当前因为系统内安装的是Drop bear SSH client，所以需要对证书进行重新制作，比较容易的做法是直接使用dropbearconvert命令进行转换生成新的证书。 dropbearconvert是一个控制台命令，先使用opkg包管理器进行安装，之后便可使用。 这样就可以生成出适用于dropbear ssh的证书：
CI4中声明stdClass类实例
最近使用CodeIgniter4框架进行宠物项目的Server端开发，因为model层还没有全部实现好，所以准备用stdClass临时拼凑一些伪代码出来，相关代码如下： 但是如上的代码是无法正常运行的，会提示没有stdClass类声明。原因是CI4框架中引入了PHP的命名空间的概念，注意到上面代码截屏的第3行就已经指定的这段代码是在App\Controllers空间下，所以其中的地14行相当于是要声明一个App\Controllers\stdClass类的实例，显然这个“空间内类”是不存在的，自然也就无法找到类声明、进而无法完成类实例化。 将上面的new stdClass()语句稍作修改，使用“绝对空间路径”指定stdClass类的空间地址即可解决。 因为stdClass类是PHP内置的基础类，它的命名空间就是在“根”下，所以上面代码修改如下，即可解决问题： 附： 我是用CI框架好多年了，可能是从CI2开始使用的吧，当初选择这个框架是因为觉得它非常的轻便、小巧，足够的简单。后来CI3发布之后也用CodeIgniter3做过一些项目，对这个框架十分钟爱。 这次开发，便也选择了CI框架，本来起初想追求稳妥继续使用CI3框架。一来比较熟悉、二来也是因为基于CI3我已经积攒了足够多的基础库，开发速度会比较快。但到底还是犯了程序员最喜欢犯的毛病——追求新技术。 使用新的技术通常情况下似乎能够带来生产力的提升，但这也许是个“假象”，新技术并不一定就真的好用，尤其是在自己不熟悉、不熟练的时候，贸然使用新的技术，往往会导致初期开发成本的增加、效率低下。 所以不到迫不得已、不是必须由新技术才能搞定的需求，最好还是使用成熟的、自己最熟悉的工具和技术，才是稳妥的做法。
闷热的三伏天
每年最闷热的日子到了，这段日子称为“三伏天儿”，“伏”大概是“藏”的意思，指的是地表阴气因为骄阳而隐藏到地表以下。整个地表都被烈日烘烤得阳气十足、再无阴凉。 也有人喜欢用“桑拿天”称呼这段日子，因为城市人不再做农事、可却喜欢泡“桑拿”，因而对他们来说，“桑拿”是个更形象的词汇、是随着新生事物诞生的新词。这个词来源于芬兰，芬兰语中的浴室或浴池称为“sauna”。 说起来估计在芬兰，人们去sauna也顶多就是冲冲水、洗洗澡吧。可城里人并不满足这样简单的洗浴形式，他们找到了更有妙趣的洗浴方式——蒸汽浴，同时再配上一个芬兰词，看上去更加的高大上、又有舶来味道。 坐在高温蒸汽房间中，借着热气腾腾的水汽将皮肤慢慢沁润、烘开汗腺，好似能够洗的更彻底、更干净、更通透、更过瘾。当然结账的时候花销也会更大一些。可是对于喜欢沉浸在体验中的城市人，这笔钱花的值得。只要体验好、感觉妙，花钱就是理所应当且无需吝啬的。 但若是让你在烈日的烘烤、高温的环抱中“享受一次免费桑拿”，恐怕很少有人乐意，哪怕免费也不会有人觉得这是享受。这着实是种煎熬。浑身不住的出汗，脖子上的汗渍反复被蒸干，从汗液中析出的盐分附着在因烈日灼伤的皮肤表面，瘙痒疼痛。 千万不要用手去抓，已经灼伤的皮肤经不住这样的力道，只会越抓越痒、如果忍受不住瘙痒而尽管解痒、解气的去抓挠，皮肤会被指甲划伤、进而瘙痒转成疼痛。这样的话即便是晚上回到家中，汗水已经洗净，白天抓过的地方依然又痒又痛、甚至红肿热辣，辗转在床上难以入睡。 所以三伏天，任谁都不大想出门免费蒸场桑拿，除非迫不得已。明智的人都会躲在房间中、最好躲在空调房中，享受着清凉，如果能再吃上一口冰镇西瓜，那才叫一个享受呢。 我便闷热的房间中苦苦煎熬，我的房间中并没有空调，仅有的风扇吹出来的都是35摄氏度的热气。不敢开窗、因为窗外吹进来的只会是更高温的热浪。只有不住的喝水、再偶尔将水拍打在头发上，三不五时的看看窗外，期待着一场雨水到来。 我在这间闷热的房间中，无所事事的 “忙碌”着手中的“电脑工作”。 这句话有些矛盾是吧？既然是无所事事、为什么要说是忙碌呢？这句话还有一些空洞无物，究竟什么是“电脑工作”？能够说出这种既矛盾又空洞的话，显然是因为我想自欺欺人。我没有任何的工作，但又不想承认自己闲着，所以就不断地在电脑上写字，写这篇文字，目的是让自己看上去似乎是个“作家”，我可没偷闲，我在创作呢。