M.2转接Intel i210千兆

2023-06-01 作者：

先说句题外话，个人不喜2.5G，一直觉得就是民用市场卷出来的临时产品。反正六类线跑电口万兆没问题，2.5G抑或10G都是贵，买个中间态产品？图便宜就留在千兆方案，不差钱直接万兆完事，2.5G这不上不下，就那么几个网卡方案不升级还断流，厂家重视与否么显而易见，对吧。

为什么要提2.5G，前两天说Tinker Board 2s带了一个key A+E的m.2，一旦做路由，这种wifi卡显见没啥用，可以考虑：

  • 另一块网卡，这样路由就不再单臂，更实至名归一些（板子还是天生12v供电，你不做路由谁做路由？）。
  • 扩SATA。也是好主意，但这板自带16GB emmc跑host和kvm足够，还空一个TF卡槽，需要的话插卡就很方便。再扩SATA就没啥必要了，并且SATA供电也得外接，板上并无接口，鸡肋了。
  • 其他PCIe设备，意思不大。

某宝上转了一圈，其实基于i225V B3（或者RTL 8125）的m.2接口2.5G网卡，居然比i210的千兆还便宜20块，赫然写着新版绝不断流……

犹豫再三我还是入了i210版本，综合考虑了自己对2.5G的不感冒，以及RK3399的转发能力，适合自己才是最好的嘛。即使接单块2.5G网卡，再做2.5G单臂路由的话，还需要2.5G vlan switch，没事咱就别给自己挖坑了。

卡么，看板子糙了点儿，但外观毕竟不能当饭吃。

 

完整阅读本篇»

为RK3399换金属壳降温

2023-06-01 作者：

这个没啥技术含量，就看愿不愿意为这么块小铁皮出90块。板子太冷门，周边没人做，所以商家估计本着开张吃半年的原则，这么个壳子收90，而且隔壁还有140的……我感觉140买x86的瘦客户端洋垃圾几乎能买整机了……

效果也比较明显，在室温影响差异不到1℃的前提下，同样被动散热能多拉下来6℃，只能说没有白花的钱，至于值不值就另说了。

完整阅读本篇»

基于CM4 Sensing双WAN冗余路由

2023-05-12 作者：

把手头能玩的板子全玩了一遍，完全停不下来。基于virt-manager和virsh cli的libvirt方案虽然没有PVE的纯web使用便利，但毕竟ARMv8有完全可用的libvirt支持已经很方便了，还要啥自行车哦。

既然Pi 4B据测已经能够很好的承担虚拟化路由职责，那么基于CM4并集成了4G LTE连接能力的CM4 Sensing就完全有能力实现双路外网的负载均衡+故障切换，对吧？

那即使技术实现上的选择已经很清晰，我们还是列一下目前已知的可能途径：

  • 基于一般Linux发行版使用iptables + connmark + policy-based routing直接手打路由。我曾用一台Debian 11 vm做过实验并且跑通了最基本的双wan负载均衡，想来感兴趣这种原始手工方式的玩家想必不是很多，所以也没有过多记录。且继续往下，在Linux上做这些策略的持久化、多ISP定时监控、故障切换，都有大量的脚本工作；而这方面已有大量成熟方案，我的目的仅仅是通过实验理解原理，目的达到，见好就收。感兴趣的可以通过关键词检索相应文章学习，另外B站的“金枪鱼之夜”的课堂录像（上下两集），可以帮你很好的由浅入深搞懂iptables。
  • 直接按Pi 4B编译/下载OpenWrt固件。如我们之前的mwan3负载均衡测试，功能实现上不应存在潜在问题，但这里显然要开始考虑4G/5G模块的驱动编译，wan口支持wwan的相应库的选择，最终编译结果固件的长期可靠性测试，硬件如果升级（比如4G模块，比如CM4载板）必然重新编译……一圈玩下来可以说是实现产品的精力了。
  • 第三个选择就要轻松的多。完全无需重新编译，把我们已经玩6的armvirt镜像直接扔Sensing里，给vm多加一个虚拟网卡eth2，打完收工。

没理解是吧，没关系，先把上一篇《基于Raspberry Pi 4B单臂路由》复习一下，接下来我们看图说话。

完整阅读本篇»

“Case Closed”

2022-12-23 作者：

So the MK-III finally got its (3D-printed) case, now the case is closed.

Yep, case closed!

Sure the case is kinda rough (sorry, 1st time stuff there…), it still reminds me of the TARS, I don’t know why though.

完整阅读本篇»

Indoor Weather Station IoT – Mk III

2022-12-11 作者：

Now it’s Mark III, having a self-designed simple carrier board with all dev kits mounted on it – seems working reliably.

室内气象采集节点，Wifi + 有线以太网两网通用，uPy固件。需要接HA的话，可以用restful sensor请求板端API，已经试过了，没毛病。这样玩的话，板子固件功能可以比esphome生成的更具自由度。

不要问我carrier board为啥选了白色，对我玩相机有印象的哥们，应该知道我备机（EOS-M3）就自己配的熊猫色，至今喜欢。

距离上次做layout，我算了一下15年有余。好在我不在乎外观，没打算从零画起，就只做了块载板。那么工作量自然也低，连原理图一起一天搞定。至于产出质量么……话说下单有点快，下完单回头review schematics发现电容接错了，又改了一版立即重新下单。

然后摩拳擦掌天天等快递，板子到手后，上电一遍过。当然一张底板，着实也是简单。

考虑到如果很多节点，server挨个请求node吧也不大合理，所以还做了个配置api地址，然后主动post数据的功能。

要问为啥不搞mqtt，呃，懒得摸新东西算个理由不？

折腾了半天，还以为想找个靠谱的asyncio http client有困难，结果还是有大佬给移植好了一版能用的。

到今天，算下来已经有三个版本了，只用业余时间，外加陪娃的话，感觉效率还凑合？

最近疫情放开，年底很多活儿堆在头上，加班免不了咯……什么时候才有精力做个壳体试试呢？

完整阅读本篇»

基于RPi和LXD的ESP32开发环境

2022-11-22 作者：

对于在板子手动重启时经常把ESP32带进下载模式的问题，LAN8720所需的上/下拉电阻恐怕是最大嫌犯。于是斥巨资近CNY 10元采购了万用板、线仔包和各种直/弯母座，终于搞了MKII —— 重启可靠性问题果然迎刃而解。

过程中，基于lxd的Debian in Debian做了套新环境，顺手也试了试C语言的esp-idf编译，用起来整体感觉很顺手。

RS232 connected with an lxc in raspberry pi 4b (not in pic)

Yes, it actually performs nicely to work on ESP32 development in debian bullseye LXD in Pi OS, no mater you’re working on hardcore C lang based esp-idf or the nice & easy micropython development.

“Hmm… so you need a standard Debian in a derived Debian? “

Well, since I found out that LXD is something very helpful to isolate different needs on different Linux distributions in different containers, while it kinda works pretty much like vm (instead of docker) since it’s easy to config the resources consumption or even usb devices pass-through, and the most important – having its own block storage which can be exported into a single archive.
Then, the only thing I can’t agree with, could be the deep connection with the snapd. Instead of switching to another distribution, such as Arch, I choose to build the LXD of my own (on both Pi OS aarch64 and Ubuntu 22.04 X86_64). Thanks to the good documentation, the stuff (native lxd without the snap crxp) works like a charm.

with Xfce and xrdp, the bullseye lxc can work as an esp dev server quite well

完整阅读本篇»