每天背着Dwarf3上班，中午花5分钟拍一张太阳，这样就能把一年的太阳记录下来。它的分辨率远超期待，因为有用望远镜拍光球层的经验，所以对于这样一个35mm口径的智能望远镜不仅能拍出本影半影，而且能拍出米粒和谱斑感到十分惊讶。它的自动曝光比较准确，不会像其他智能望远镜那样日面大部过曝，这也是能够拍摄出米粒和谱斑的关键。拍摄星云时如果愿意积累足够的曝光，那么其实细节和信噪比也是能够一观的。星系拍摄就有点勉强，绝大多数星系用等效737mm的望远镜拍出来都是只有一点点，但是星系照片有意思的地方就在于一张照片中往往有不止一个星系，想到每个模糊的亮斑都是一个不亚于银河系规模的星系，那种上帝视角的感觉也是十分奇妙啊。

        盘点了一下，2025年划水的次数还真不少，划得最多得地方还是抚仙湖，现在把艇和桨板也丢在星空小镇了，希望来年能划得更多些。

        2025年跑了三场半马，大理、上合和抚仙湖。

• 大理：风景绝佳，海拔偏高，值得跑...一次
• 上合：还是那条赛道，还是那种让人摸不到头脑的赛事组织，好在每年的完赛奖牌都设计得十分大气，今年取消了上合跑和亲子跑，名额都加到了全马和半马上，中签率提高了，去年的上合半马就没中。
• 抚仙湖：心心念念一直想跑的半马，去年中签了完赛奖牌还特好看，可惜赛前感冒咳嗽不得不弃赛，今年终于得偿所愿，但抚仙湖边的赛道远没有想象中的美丽，离水面太远喽~~~应该不会再跑了，但小城市的热情是大城市里感受不到的，于是抚仙湖半马的经验就是：有机会应该多跑跑小地方的马拉松。

        一开始，对智能望远镜是十分不屑的。原因很简单：无论Seestar还是Dwarf,价格连一台画质过得去的摄星镜都买不到，会有什么意思？但当我一次又一次跋涉几个小时到达一个地点，再花一两个小时调试设备，想着还要再花几个小时顶着黑眼圈开回家，心中就泛起一阵无力感。能经常用，比性能优越但难以搬出门要有用得多，能够感悟到这一点的人，一般都是经历了各种折腾与尝试，如果你想通了，智能望远镜就是最好的选择。当然，如果你是天文小白，下手就选了它，我只能说，你少走了很多弯路，你比很多新入门的天文爱好者都要幸运。

        Dwarf3的使用感受：

• 工作确实比较稳定，除了开机连接机器略微慢了一些，APP和机子用下来都很稳定，没有异常退出什么的情况。
• 界面比较简单直观，一般不用看教学视频就能上手，然而星图部分简陋了一点，搜索到目标后无法显示升起落下时间，不便于规划拍摄张数，星图界面上也没有东南西北的标记，和很多星图软件比起来确实过于简单了一点。
• 星野拍摄，例如星轨、星空延时之类的在界面上没有直接的选项，没用过的话，第一次用会感到困惑。
• 叠加成功率不算高，我架在楼顶，大约60-80%的片子可以叠加，然而看单张可以发现，有的起雾了，有薄云遮盖的仍然被当作好片叠进去，所以想画质更高些的还是需要人工选片后再叠加。
• 自动对焦可用，但不算太准，我的经验是如果是深空拍摄，AF后用鱼骨板进行对焦，大约要手动调整2-4个单位，如果是太阳月亮拍摄，实时画面放大到最大进行目视微调，大约要微调1-3个单位。
• 赤经轴应该有空程，逐张看片时会发现画面不规则移动会有点大，导致叠加后周边一圈是需要裁切掉的，还好长焦4K的分辨率，切掉了还能有足够的像素。
• 画质不能和冷冻CCD比，哪怕是十五年前的QHY8L，都比它画面干净得多。但是它的灵敏度比八爷高太多了，相同曝光时间，它的细节更多。
• 以上所有感受，来自于7级光污染区楼顶双窄滤镜拍摄的经验。换一个光污染小的地方，不像楼顶那样晃，用天文滤镜而非双窄滤镜，好好拍上一组暗场平常偏置场，好好做做后期，应该还有不小的提升空间。这也是大家说Dwarf更适合有经验天文爱好者的缘故。

        实现了消息发布订阅和数据存储，接下来就是怎么用数据了。数据展示就是可视化，可以用的软件很多，Grafana是开源软件中用得最多的（吧？）。由于用的人多，教程也多，所以只要注意以下几点就行了：

• 安装包去官网找，安装过程很详细，只是要记得一定要选择和自己主机的CPU和操作系统对应的安装包，否则安装不成功。
• 打开端口。
• 新建仪表盘时，如果SQL语句写了后可视化窗口里却空空如也，那八成是没有指定数据库，引用的表要写成XXX.YYY，其中XXX是数据库名，YYY是表名。

        二十多年前，似乎还在用着33.6K的modem时，MP3刚刚发明出来，在网上慢吞吞地下载了很多歌曲和乐曲，很多很喜欢的歌曲和乐曲就是那时候发现的。只是那时候网上的搜索引擎功能还很弱，网上的信息也很少，即使觉得一首歌很好听，也找不到有关这首歌的太多的信息，尤其有时候歌名都不完整，就比如这首小号曲，下载下来的名字叫wonderland，在用上apple music后就用这个名字搜，无奈同名的太多，都不是这一首。直到前天在微信的视频号中发现有人发这首，才知道了这首曲子的全名，用这个名字果然也在apple music中搜寻到了。嗯，果然对于音乐来说，微信视频号比小红书强多了。

        EMQX接受到消息后，存储到TDengine数据库的方法就是设定规则，方法如下：

• 建立规则，用SQL语句把需要存储的消息及相应字段筛选出来（有可能接收到的是发布端的心跳包，这个是不需要存储的）：SELECT XXXX,payload.XXX,XXXXX,XXX,XXX FROM "XXX/XXX/XXXX" WHERE is_null(payload.XXX)=false
• 在规则的动作输出中选择TDengine，写一条在数据库中插入数据的SQL语句：insert into XXXXX using XXX tags('XXX','XXX') values (${XXX},'${XXX}', ${XXX}, ${payload.XXX}, '${XXX}'),第一个字段记得永远要用时间戳，字段是int或者float的，不需要加''。
• 在规则建立页面有调试功能，可以在设定规则后，用MQTT.fx发布数据，然后观察是否成功存储到TDengine中，以此来判断和排除语法错误。
• TDengine是时序型数据库，规范建表的方法是先建超级表stable，需要存储的字段都在超级表中事先确定，然后每个设备用一个新表table存储数据，表会继承超级表的字段，不需要再次定义，但也意味着不能随意修改增减，所以超级表设计时一定要考虑周全，否则只能逐个增加超级表的字段。
• 规则的动作输出也可以选择为消息再输出，把筛选出来的消息以另外一个主题重新发布出去。
• 同理，当规则的SQL语句中增加了数据的比较和筛选功能（如数值大于或小于某个设定值时），再设定一个消息再输出，就实现了报警功能，这样做的好处是规则的设定完全是在服务器端，前端硬件设备不需要做任何设定，这样灵活性无疑大了很多。筛选出来的数据同时也可以存储到TDengine中，实现报警数据的记录。

        Arduino调试过程中，会出现一些匪夷所思的问题，表面上看来是闹鬼，其实都各有原因，只不过原因隐藏得比较隐秘。比如：

• 用UNO调试一个电路，当单独挂载一个SSD1306的IIC屏时，使用例程和自己的程序都正常，但一旦放到一个有三个IIC器件的系统中就始终无法编译通过，想过可能是地址的问题，但查下来地址都不重复，最后发现是通常用的SSD1306库文件消耗内存太大，UNO这样的内存有限的MCU当只运行这个库时没有问题，一旦加载的库多了，内存就不够分，体现在在编译显示分配失败。解决办法是找一个内存消耗小的库，或者换成MEGA2560，显然前者更有可行性。
• 一个串口屏的应用，接收到信息后报警，用一个按钮中止报警修改报警背景颜色，结果程序编译完成后其他功能都正常，唯独串口屏无法显示设定的初始界面，总是一晃就变成空数据界面，怎么调整程序都不行，最后发现是按钮对应的IO口异常，虽然软件做了上拉，但高电平时只有2V，造成进入LOOP循环后程序认为按钮已经被按下，串口屏自动显示报警中止后设定的画面，此时又没有数据，只能显示一个空数据画面，换一个IO口就一切正常了。
• Arduino里将时间戳转换为正常的日期和时间格式，网上的Arduino time库现在的IDE用不了，试验了安装time库可以进行转换，然而转换出来的日期和时间始终不对，最后发现这个库的转换功能只能用于转换10位的时间戳，如果你用的是13位的时间戳，那必然不对，需要先将13位的时间戳截取为10位，才能正确转换。
• 在程序开头将某变量设置为全局变量，在子程序中如果再次对该变量进行类型定义，则不会报错，但该变量数值仅能在子程序中保持，无法在其他子程序中读取，即事实上失去全局变量作用。

        UsartGPU串口屏是最常用的串口屏，最近在应用过程中遇到问题，串口语句在GPUMake中显示正常，但移到Arduino后就始终无反应。经过长时间排查，直到查阅了厂家网站www.ai-diy.cn上的文档才发现问题所在，这几个坑真不容易注意到，下次应用一定要注意：

• 要在串口屏上显示汉字，不能在Arduino IDE中直接引用汉字，因其编码格式为GB2312，而串口屏需要ANSI格式，解决办法是在记事本里以ANSI格式新建一个hz.c，里面写一条语句 const char hz[][32]={"XXX","XXX","XXX",......}，每个字或每个词、短语作为数组元素添加其中，注意数组的长度要因放入的汉字多少而定，一个汉字需要两个字节。将其放到ino文件的相同目录中，在编写Arduino程序时将其纳入：#include "hz.c"，在发送时用hz[X]引用相应汉字。
• 发送一堆串口命令时，一定要在最后一条串口数据发送时加上换行符：Serial.println("XXX");否则串口会认为命令还没有接收完毕，不会有任何动作。
• 如果屏上显示有稀奇古怪的问题，一定是在串口数据编码过程中出现了格式问题，比如少了一个），引用hz[X]时要在其前后加上'。
• 串口屏使用的是GB2312编码，Arduino用的是UTF-8编码，后来发现一个不需要很麻烦的办法：在Arduino中安装UTF8TOGB2312的库，就可以在程序中实时转换编码，实现串口屏的中文文字实时显示。

        搭建方案是让DeepSeek帮助制定的，技术路线是：EMQX作为MQTT服务器，通过设定规则和连接器将接收到的信息传送给TDengine时序数据库存储数据，用Grafana作为数据可视化工具。安装调试过程中颇掉了不少坑，记录如下，以后再部署时避免弯路。

• EMQX与TDengine安装时注意选择与操作系统适配的版本。
• TDengine安装后，要启动taos适配服务：systemctl start taosadapter，否则与EMQX的连接无法成功。
• 使用公众云平台部署时，EMQX要打开1883，18083等端口，TDengine要打开6041端口。
• EMQX里设置规则时，SQL的语法与MY SQL的语法并不完全一致，有的语句和功能无法直接使用，要查阅它自己的SQL语法手册，TDengine同理。
• EMQX和TDengine在同一台服务器上部署时，如果不使用Docker,连接器地址要选择127.0.0.1:6041，用Docker部署时则用相应容器的地址。
• MQTT消息的格式一般会用JSON格式，同一台终端可能同时会发送心跳包（特定字符）以维持连接，在转发存储时设定规则，可以在SQL语句尾部加上 WHERE is_null(payload.XXX)=false 以过滤掉非JSON格式包。
• TDengine在创建数据库时，一定要加上数据保留周期 KEEP 365，这是保存一年，如果不设定，默认保存10年，服务器空间压力太大。要加上允许修改的参数 UPDATE 1，否则只能整个表删除。
• TDengine建数据库后先建超级表，把需要记录的字段设定后再建子表，子表继承超级表结构，只用设定TAGS来说明终端的位置和类型等即可。
• 虽然有人物联网的CAT-1模块在透传模式时只用向其发送JSON数据，但在EMQX接收时会收到包括时间戳、用户ID、QOS等信息在内的完整数据包，可在EMQX规则设定中打开调试模式试验查看。数据戳来源可解析收到的payload.timestamp，也可以直接引用函数NOW。