NtripShare的专栏

NtripShare测量机器人自动化监测系统测站更换仪器后重新设站

NtripShare全站仪自动化监测之气象改正

NtripShare Mos地铁自动化监测终端盒子硬件设计

NtripShare Cloud GNSS解算云平台之动态、快速静态、静态解算

GNSS观测数据及各种产品下载网址

也有很多朋友提出了一些产品性的通用问题，趁着五一期间有空，对NtripShare Cloud GNSS解算云平台进行重大更新与调整调整，暂时命名为V3.0吧。4、改进网平差逻辑，将网平差绑定到基线，当所绑定基线全部解算完成时，进行自由网或约束网平差。以上是V3.0主要更新内容，尚未正式发布，朋友们如果还有其他共性需求，欢迎交流。2、增加基线概念，可任意组合两个站点为一条基线，基线可配置解算参数。1、去除基准站与监测站概念，仅保留站点，站点配置平台接收数据参数。

NtripShare Mos地铁监测云平台与监测终端盒子架构设计

NtripShare 地铁监测系统系列软件&终端即将面世

NtripShare EdgeEngine GNSS边缘解算软件

NtripShare Cloud GNSS解算云平台之卫星观测质量检核报告

NtripShare Cloud数据接口说明

NtripShare EdgeEngine GNSS边缘解算盒子/模块/软件用户手册

NtripShare GNSS系列产品家族2022，GNSS静态解算，边缘解算盒子

看了一下最近的更新日志，仅仅是处理了一些NtripShareCloud的BUG，对于NtripShare系列软件前进方向没有了思路，有几个方向被我自己毙掉了。1、继续完善PMonitor桌面版监测解算软件，使其成为可独立交付的商用产品----毙掉----没有新意，不想跟现有监测解算软件走相同路线。2、继续完善NtripShare Base、NtripShare Pro、RTK差分共享猫开源系列----毙掉----之所以开源是因为精力不够且希望有志同道合的人一块做这件事情，目前为止没有找到合适伙伴，绝

趁着元旦假期，把NtripShare Cloud中想做的部分又补充了一下，主要处理两个问题，解算时自动进行原始观测数据质检，及解算后对解算结果的滤波处理。目前NtripShare Cloud静态解算的数据解算流程如下图所示，与各家解算软件稍有区别，基本上打通小异，再附上一张观测数据自动质检的图，欢迎交流，VX：NtripShare...

NtripShare Cloud静态解算之卡尔曼滤波

最近有空重新梳理了一下自己GNSS系列软件家族，NtripShare系列软件历经一年，关注于差分数据播发与解算，作为2020-2021年的成绩单，勉强可以交差，还是希望能与各位朋友加强沟通交流，欢迎骚扰测试。RTK差分共享猫APPPmonitor 2020NtripShare CloudNtripShareEngine...

昨天对以为朋友的城市区域的监测站数据进行分析，主要原因是这些站点在NtripShareCloud中的解算效果一直不算理想，且非常的不稳定。分析主要原因如下：1、接收机本身网络性能不足，导致观测数据在传输过程中存在丢失的现象。2、接收机本身性能不够稳定，观测数据断断续续。3、站点所在区域存在遮挡及干扰情况。以上原因是我个人观点，如有大神有不同观点请联系我讨论，观测序列图如下图所示。针对网络和接收机本身的问题我表示无能为力，对于遮挡及干扰影响解算的情况，NtripShare最近加入了自动

趁着周末有空，对PMornitor 2021版本精度进行测试，本次测试内容为对比新加入的平差模块与原始解算效果对比测试，感谢深圳大学提供测试数据源。测试设备： 1、基准站设备：septentrial马赛克系列板卡接收机*1，数据流RTCM，数据频率1HZ。 2、监测站设备1：天宝BD970板卡接收机*2，数据流RTCM32，数据频率1HZ。 3、监测站设备2：STL接收机，HXXT板卡接收机*3，数...

好多朋友询问最近在忙啥，博客太久没有更新了。这个夏天有点忙，一来工作太忙、二来江郎才尽，最近没啥好的想法和思路。但是....每一次的蛰伏都是为了更好的破茧重生....历时接近两个月PMornitor GNSS基线解算系统2021基本开发完毕，正在进行内测......

一、整体工作流程二、TCP数据接收TCP数据接收基于DotNetty框架实现，涉及类NtripShare.Server.NettyServer-数据接收主体类，NtripShare.Server. ServerHandler-数据接收处理类。2.1 NtripShare.Server.NettyServer2.2 NtripShare.Server.ServerHandler三、数据文件保存TCP数据接收后已原始数据文件保存，涉及类NtripShare.Utils.F

动态解算完成之后，原计划增加天线和坐标系统模块，考虑到当前系统中用到的一些第三方库缠身的效率问题，思前想后，心一横把用到的所有库重写，这酸爽，就是掉坑里出不来了....需要吐槽一下某些第三方的库，写的实在太烂，效率太低。至此NtripShare GNSS系列软件家族如下：顺带更新了一下NtripShare Cloud的部分bug，有个问题很头疼，netty框架接收数据判断设备是否在线，做了一个数据集，netty接口上线添加、下线删除，居然会出现是否在线不准确的情况，有解决方案的朋友麻烦你们教

经过差不多两周时间，实现了实时RTK解算与Ntripshare Cloud的集成，实现实时的RTK解算与静态解算的同时处理，效果如图，目前Ntripshare Cloud的基本架构如下图，至此GNSS部分想做的具有难度的事情做完了，后面就是漫长的补充功能与修复bug的过程，欢迎大家一块交流与测试，VX：Ntripshare...

有很多行内朋友提出，需要在服务器端进行RTK动态解算，一直以来都觉得任何一家的板卡内部都自带RTK实时解算，没有必要耗费精力去研究。最近一位朋友的应用场景说服了我，在某些项目中，网络限制只能采用内网模式，接收机本身不能直接从外部获取差分数据源，内部网络又只能采用单向通信的模式，导致RTK实时解算只能在服务器端实现。为了实现RTK的实时解算，对原软件从架构上进行了重新的思考，参考某厂家的解算软件设计模式，PMornitor初步实现服务器端的RTK动态解算，架构改造后一些bug应运而生，缓慢修复中...

过年期间无心干活，给大家拜年了！！！应朋友要求验证长基线解算精度，朋友提供了一个站30天的数据进行了长基线解算精度测试。测试条件如下：1、测试设备：Trimble2、基线长度：100KLM3、数据频率：15HZ分别截取2小时、4小时、8小时数据进行解算验证、效果如下。结论：1、在两小时解算数据长度下，解算精度为为厘米级，解算精度并不稳定。2、在4小时以上数据长度下，平面解算精度基本维持在毫米级，高程精度约5cm左右。...

今天对平台进行了一下压力测试。测试项目： 1、监测站实时接收数据压力测试； 2、 静态解算压力测试。测试设备： 1、基准站设备：天宝BD970板卡接收机*1，数据流RT27，数据频率1HZ。 2、监测站设备：天宝BD970板卡接收机*2，数据流RTCM32，数据频率1HZ。测试方法： RTKLib转发基准站数据至平台...

离职赋闲在家，一直忙于RTK差分共享猫，变形监测解算软件好久没有更新。耐不住一直有行内朋友想要试用，发现主要问题如下：1、软件计算资源耗费较大。2、站点增多会导致软件界面卡死，但是解算仍在进行，由解算过程单线程计算导致。3、如采用10分钟解算频率，6小时解算时长，变形发生要在6个小时之后才能正常反应实际值，由软件直接采用6个小时数据计算导致。4、司南、天宝数据流星空图无法正常显示。针对以上几个问题，对软件进行了升级，主要工作如下：1、增加线程池计算，每个监测站每次计算开辟单独线程池中

最近离职，时间上相对比较多一些，对GNSS的变形监测软件进行更新，主要更新内容如下：1、增加三位无约束网平差（事实证明采用多参数均值算法后，三维无约束网平差并不能提高解算精度）。2、增加对sqlite数据库的支持，解决大家拿到软件安装包后无法自己安装的问题。3、修复部分bug。因换工作原因，可能以后无力更新软件，GNSS变形监测软件源码寻找有缘人，欢迎交流...

最近一周对监测软件进行升级修正，主要改动包括：1、加入对平面坐标系统支持。2、优化界面设计。3、优化观测信息试试展示，包括星空图、信噪比图等。问题总结：1、采用平面坐标系解算结果中平面精度比采用空间坐标系的xy差值要小，高程要打。2、2小时解算结果精度比1小时解算结果精度提高明显。...

许久没有更新过博客，一是最近在换工作，无心研究。二是最近研究进展缓慢。朋友提供了五个监测站点，原来用阿里云服务器，解算结果一直不稳定，一度让我怀疑人生。最近换成了腾讯云，解算效果令人满意，效果如图，严重怀疑阿里云在带宽上打了折扣。欢迎交流！...

由于变形监测软件的解算稳定性问题，这两天拿了一批朋友的数据，对某静态解算软件解算进行进行了分析，数据为天宝BD970板卡的观测数据，供六个时段，每个时段1个小时，数据频率为1HZ。解算结果如下：不同解算参数：解算卫星：gps---gps&北斗频率 L1---L1/L2卫星截止高度角： 10度--30度解算结果如下表：30-50-L1L2-双星 10-50-L1L2-GPS 10-50-L1L2-双星 10-50-L1L2 10-50-L1 10-

最近对GNSS监测软件进行升级，包括偶像哦啊几个方面1、修改解算策略为卫星高度角多次解算，即利用不同卫星高度截止角进行多次解算，取精度最高为最终结果。2、原dll库对RTCM数据转换Rinex后丢失星历数据，改用RTKLib进行Rinex格式转换。3、增加对司南数据格式支持。4、增加历史数据导入功能，选择数据文件自动识别基线，自动解算。5、修改监测曲线为绝对数值和相对数据两种变化曲线。5、修复软件现存Bug。...

原来一直用朋友的天宝接收机进行变形监测软件的测试，基准站数据流为RT27，这两天有朋友用了一款过国外板卡进行测试，数据流采用了RTCM32。奇怪的是在Rinex转换过程中始终无法发现星历数据（用的某厂商的数据读取库），然后拿RTKlib进行rinex格式转换，还是不行，但是朋友发过来用RTKlib转换的数据没有问题。历时一晚，发现我用的rtklib为2.4.2，朋友的rtklib为2.4.3，替换版本搞定，太坑了。果断将原有数据格式转换库替换为rtklib2.4.3，转换代码给大家贡献一下，欢迎交流

昨天的静态解算结果一直处在2MM以上，无法满足朋友对精度的要求，今天将解算参数进行了调整，将卫星截止高度角提高到30度，效果明显，稳定2MM。解算结果如下：13:00-15:00.基线解算结果* 解类型 DX(m) DY(m) DZ(m) 中误差_DX(mm) 中误差_DY(mm) 中误差_DZ(mm) RMS(mm) 浮动_L1 1.6676 0.2392 ...

最近朋友提供一份观测数据，想验证一下监测软件的解算精度，用多种策略解算了一下，结果如下第一组，不同解算时间，L1和L1L2两种解算方式：1小时L1L2广播星历.基线解算结果 解类型 DX(m) DY(m) DZ(m) 中误差_DX(mm) 中误差_DY(mm) 中误差_DZ(mm) RMS(mm) 浮动_L1L2 -1.3083 0.5784 -1.9497 ...

GNSS变形监测最近进展缓慢，一是最近项目确实忙，二是数据解算确实很难，总结最近一个月来进展情况1、添加精密星历解算。2、支持L1L2解算。3、添加RTK实时解算。4、修正对数据的星空图及信号强度展示。...

最近又对gps变形监测产生了浓厚的兴趣，跟朋友讨论一番就开始下手，无奈工作实在太忙，断断续续接近2个月，终于满足了GNSS变形监测的精度基本要求，一小时后定位精度2MM，可以设定时间进行自动解算，支持RTCM、RT27，支持Mysql数据库，查看测站卫星分布及信号状态。中间过程崎岖坎坷，原设想RTKLIb直接可以解决问题，越做越难，不必细说，总结一句话，真的很难，为广大科研工作者点赞，上图.......