软硬件使用

各种应用软件、硬件的使用技法记录,以备不时之需

给快20岁高龄的明基海湾A110键盘续了个命

这款明基键盘是04年时购买的,当时一位学长买了这款键盘,我体验了下当场就爱了,从来没有用过这么好手感的键盘,后来才知道X架构之类的细节,而且也很喜欢这款键盘的键程,比笔记本键盘的那种巧克力按键要高点,但又没有标准键盘那么高,敲代码玩游戏都非常舒适,即使是今天换了机械键盘,也依然很怀念明基X架构的键盘(后来工作了又买了一把海贝A800,按键手感相同,不过弯曲的形状感觉不如海湾)。遗憾的是这把A110在20年时出现了Y键失灵的问题,最开始时偶尔还能有反应,但是后来就完全不行了,然后没过多久下面的H也出现了类似的情况。当时也尝试过修理,但是没找到问题,拆开键盘后清理了下,扒出薄膜来看了下,不像之前拆过的廉价键盘,薄膜电路很复杂,而且还有胶粘住(估计是为了防水),上面那层已经有很多氧化发黑的银线了,不过应该不影响封在内部的上下层间按键接触导电。由于当时没有银漆,又急着用键盘,于是就封印了A110,买了把机械先用着了…

Continue reading…

W801开发板Upgrade Tools上传程序失败问题

继之前的Arduino Nano之后,最近又搞了一片国产的W801开发板研究,陆续装上了CDK IDE和W80X SDK v1.00.10后,算是能编译自带的Demo程序了,整个过程对比下来对新手的友好度明显不如Arduino,后者基本上能做到装好IDE后一键部署点灯程序,不过这个MCU功能强大,整个开发板又只要9块9,生态差点就差点吧,要什么自行车!在百度了不少资料,搞明白怎么上传变好的自带demo程序.fls文件后,打开联盛德的Upgrade Tools,打开串口,选好fls文件,点击下载,duang,挂掉了,提示:

Waiting for receive CCC …

CCCC

==

Sync success, W80X

BLE MAC: 286DCDD1495B

WIFI MAC: 286DCDCE3C1B

FID:85,15

Please wait for Erase flash …

CCCC

Erase flash ok.

Try 2000000 baud download file …

Start the download image_0.img

Start the download image_1.img

Download “D:/C-Sky/W80X SDK v1.00.10/bin/w800/w800.fls” fail! Error code: “CAN”

LLLCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC

然后就是一直刷CCCCC(后来才知道,这是这个开发板进入等待上传程序的信号,怪!),又试了几次,一样的现象,大概在进度走到30%左右就会fail….

Continue reading…

小米米家温湿度计2的正确重置(复位、恢复出厂、reset、触点按不动)方法

家里三个小米温湿度计2,连着小米智能插座2的蓝牙网关,小巧方便,手机随时查看家里温湿度情况。最近其中一个在更换电池后,出现了奇怪的问题:米家app上能看到设备,并且也显示已连接蓝牙网关,但是温湿度数据就是获取不到,点进设备详情界面也一直没反应,提示“打开蓝牙”,此时如果开启手机蓝牙,会以很慢的速度通过蓝牙连接设备,然后确实可以正常获取到数据,只是整个过程反应很慢,不像之前网关正常时随点随出,同时这样在外出时也看不到这个温湿度计的实时信息了(从米家app的中枢网关界面里也能看到这个温湿度计是连接状态,并且离着不远三格信号满格),后来看了下固件,发现可以升级到最新的“0130”,于是升了下级(这个过程也是特别慢,不知道是不是由于蓝牙传输所致),升级完成后问题依旧!百度搜索了下,发现有人提到可以重置一下试试,然后就进入了今天记录的主题,这个小米温湿度计的重置设计也算是另类了,网上能搜到的重置方法基本都是这样说的:

Continue reading…

关于Si4735的SSB Patch(pu2clr开源项目)

最近在研究基于Arduino + Si4735 + pu2clr/SI4735的数字收音机,FM功能基本已经ok了,感谢pu2clr开源项目作者 Ricardo Lima Caratti 封装了这么好用的库,电路连接正确的情况下,基本可以秒实现功能!

简单试玩了一段时间后准备挑战下传说中的SSB单边带补丁,结果踩到了一个小坑,使用pu2clr库中的代码:https://github.com/pu2clr/SI4735/blob/master/examples/TOOLS/SI47XX_09_SAVE_SSB_PATCH_EEPROM/SI47XX_09_SAVE_SSB_PATCH_EEPROM.ino,准备将SSB补丁写进AT24C256 eeprom中,结果发现执行代码后,数据写入出现了问题,所有验证过程读回的数据全都是0xFF,patch的name什么的在Arduino IDE的Serial Monitor中看到的也都是乱码,size也都是FF对应的错误数据65535这些…

Continue reading…

logcat read failure问题的排查修正记录

上次给退役的一加1刷了lineage-16.0后,本来一直使用的挺好,当个备用怀旧游戏机还挺流畅的,最近拿来做一些安卓调试时突然发现logcat没反应了,AndroidStudio里一片空白,adb设备状态一切正常,尝试adb logcat以及adb shell后logcat,发现会提示“logcat read failure”这个错误,查了半天,尝试了个各种手段,root su进到/system/bin下看logd完好无埙,又看有人说是selinux的问题,ls -Z检查了logd的权限:u:object_r:logd_exec:s0,发现也没问题。然后又以为是装Magisk装的把系统搞坏了,于是有恢复出厂了一次,结果发现错误依旧!最后突然想到之前的系统镜像貌似是不知道哪个瞎八网站上下载的,本来里面就内置了一堆乱起八糟的app,会不会是不靠谱的rom作者把重要功能给改坏了?于是废了半天劲找了个lineage官方的旧版本系统镜像:https://lineageosroms.com/bacon/#installing-lineageos-from-recovery 然后又重刷了一次机,果然,纯原版的镜像是没有问题的,logcat恢复正常了。

[ZT]Qt开发环境安装程序跳过账号登录的方法

记录一下,Qt开源版开发环境安装程序,跳过账号登录的方法,参考自:

https://www.openguru.com/2021/03/install-qt-creator-without-qt-account.html

首先是要下载Qt离线安装程序,在这里:https://www.qt.io/offline-installers,然后安装时会发现还是需要登入账号,此时linux系系统可以设置无效proxy,如上面参考链接中提到的方法,而windows则可以通过禁用网络连接的方式跳过

Windows的符号链接SymbolicLink(快捷方式)在网络共享访问时的跟随跳转问题

这个问题发现于这么一种操作,首先是用Powershell脚本进行快捷方式(SymbolicLink)创建:

New-Item -ItemType SymbolicLink -Path d:\share_folder\ -Name latest -Target d:\share_folder\v1000 -Force

此命令在d:\share_folder文件夹中创建名叫latest的快捷方式,并指向同级文件夹中的v1000目录,然后将share_folder开启网络共享,从另一台机器通过 \\xxx.xxx.xxx.xxx\share_folder方式访问这个快捷方式latest时,发现会提示:“无法遵循符号链接,因为其类型已禁用”的错误信息,百度一下,查到原因,参考:Windows 挂载磁盘错误 ‘无法遵循符号链接,因为其类型已禁用’ 解决方案 https://www.zywvvd.com/notes/system/windows/symlink-disabled/symlink-disabled/

原来Windows默认对符号链接的跟随跳转仅限本地,远程到本地(共享里的快捷方式指的本地路径),远程到远程(共享里的快捷方式指的是另外的共享路径)都是禁止的,于是参考上面的解决方案,fsutil behavior set SymlinkEvaluation R2L:1 打开远程到本地的遵循,结果再次访问时发现提示目标文件夹不存在!

Continue reading…

一种FFmpeg提示“dts < pcr, TS is invalid“的解决方法

此问题出现在使用FFmpeg(动态库)输出UDP+TS流且开启muxrate输出CBR时,音频为aac编码,视频为264编码(libx264),视频部分使用vbv-bufsize及vbv-maxrate和nal-hrd=cbr编码CBR码流,可以看到程序刚跑起来FFmpeg的log回调就会疯狂报标题里提到的dts < pcr警告,这个警告的源码位置只有一个,就在libavformat\mpegtsenc.c的mpegts_write_pes这个函数里,但是读了下代码,也没看出来为什么会报这个警告,后来找到了这两篇参考:

FFMPEG转码音视频不同步情况总结 https://blog.csdn.net/liuchen1206/article/details/79461434

ffmpeg 奇葩问题2 https://blog.csdn.net/WaitForDone/article/details/78030095

其中第一篇参考文章里提到了编码速度问题,提到去掉B帧这个操作,而我的应用直接设置了zerolatency的tune相当于也是不带B帧的编码,第二篇文章提到了几个点,一开始直接放到了结果上,疯狂尝试各种qmin、qmax设置,结果都没有见效,而且实际发现我的视频码流并没有文章作者提到的编码出来的视频帧偏大的问题,其实用的就是默认的量化值,每帧大小也基本符合整体目标码率,最后百思不得其解时,试了下直接用ffmpeg命令行进行同样参数的编码操作,发现并没有报这个“dts < pcr”的警告,而且是跑了很长时间后也一次警告都没有,又结合了下第二篇参考文章中提到的delay设置,于是开始比较ffmpeg命令行程序的各种format、codec初始化操作参数,最后终于找到了问题:

Continue reading…

使用Win10 + WSL编译FFmpeg时的依赖库处理

Windows 10的Linux子系统WSL安装过程就不做赘述了,网上资料很多。

之前一直认为WSL只是以类似虚拟机或容器化的方式使得能在Windows上运行原生Linux程序,当然,也在WSL上做过如使用ndk交叉编译Android原生程序、动态库的操作,用起来还是挺方便的。直到最近研究FFmpeg的Windows版编译时才发现(参考自:https://www.bilibili.com/read/cv7058269/),原来WSL还有一个“大杀招”:直接运行Windows执行程序exe,如下图所示:

可以看到,在WSL内直接执行VS 2019的编译器程序cl,也是完全没有问题的,基于这种方法,FFmpeg官网上所说的用cygwin,mingw,msys之类的桥接环境构建Win版FFmpeg的麻烦就不复存在了,而且新版FFmpeg源码(博主用的4.3)的configure也做好了对这种编译方式的支持,参考上面的链接,制定上toolchain=msvc等相关参数,剩下的事和nix系统上构建一样就可以顺利完成了,简单方便!

不过,今天要记录的并不是WSL下编译Win版FFmpeg的问题,而是编译时如何引入其它依赖,如openssl,xml2等以获取更多功能支持,尤其是在Win环境下,这些其它依赖库的位置很有可能是一个很随意的位置,而在WSL环境下处理这种依赖的头文件、库文件搜索路径时是有坑的…

Continue reading…