最近一个杭州的客户，使用合宙的 Air201——4G资产定位模组，做室内wifi定位，发现在同一园区不同楼栋内定位结果相同，找到我们希望做问题排查。

排查过程记录在这里了，如果你也有类似问题，希望可以帮助到你~

一、了解客户情况

我第一反应是，客户的定位流程可能有问题。

让客户出示了两栋楼中对应的AT流程，流程如下：

一号楼：

五号楼：

 

看了一下，似乎也没有什么问题。

对比来看，两栋不同的楼栋，定位结果完全相同。

给我人看傻了，马上都要自我怀疑了，不可能是合宙的wifi定位服务器的问题啊，我们产品发布前做过无数次测试，像这种楼和楼之间的定位是很精确的，是绝对没有问题的。

二、原理分析

思来想去，还是要从wifi定位的原理去分析。

实际上，wifi定位原理就是模块收集周围wifi的mac地址和信号质量，然后带着这些信息去访问wifi定位服务器，由服务器去自己数据库里搜索对应mac地址，再根据信号质量确定设备离对应的wifi信息源距离，进而返回对应坐标

(注：合宙使用的是高德的付费数据库然后释放出来免费给用户使用！[他真的，我哭死])

知道了原理后，我指导客户，使用"AT+WIFISCAN"这条指令，主动显示出周围的wifi信息。

我拿着这些信息，手动去访问一下高德的定位库，看看是不是高德认为这两栋楼是同一个地方。

下图是客户两栋楼不同的wifi信息：

一号楼扫描到的WIFI：

 五号楼扫描到的WIFI：

很明显两栋楼的wifi信息也不一样啊，按理说不应该显示同一个地点啊。

不死心的我，拿着这个信息又去请求了高德的定位(由于是付费库，此处仅显示定位出的结果)

 

可以很明显的看到，不是一个地方，那么为什么我们服务器返回的却是相同的地方呢?

我想了又想，有没有可能，是高德使用的是GCJ坐标系,而经过我们服务器下发给用户的时候，由于用户习惯的坐标系不同，所以服务器经过GCJ坐标系转换成了WGS-84坐标系的dd.dddd格式，是不是坐标转换或者格式转换的时候丢失了精度。

于是我将上述两个经纬度，转换成了WGS-84坐标系的dd.dddd格式，

再根据信号质量确定设备距离离对应的wifi信号源之间的大致距离。

(完整代码请参见GPS 定位纠偏 - Luat，让通信更优雅 - 上海合宙通信科技有限公司)

 

 

 三、查看手册，找到答案

转换过后看了一看，这也不是同一个地方啊，那为什么模块返回的是同一个地方呢？

我百思不得其解，于是又返回去对照AT指令手册

(AT手册可以在这里找到Luat4G模块EC618& EC716& EC718系列AT命令手册)

仔细看了下客户最初的AT指令流程，对比AT手册上的描述，发现了端倪：

客户的流程缺失了一个设置：

如果没有使用AT+WIFILOC设置wifi定位优先，则默认使用的是基站定位。

由于一座4G基站理论上可以管1.5km内的几乎所有设备通讯，所以客户不管是一号楼还是五号楼，都连的是同一个基站。

如果你使用的是合宙免费的单基站服务，那么基站定位的返回的肯定是同一个结果。

猜想成立，于是问客户要到了设备的imei号，和合宙定位服务器那边对线了一下，确定了这个客户上传的信息只有基站信息，所以服务器一直返回的是基站定位的结果.

问题终于找到了!

四、问题解决

和客户沟通后，客户使用AT+WIFILOC指令，设置完wifi优先后，再次去实地验证，果然定位结果不同了。

 

问题找到了，客户很高兴！

五、个人分享

作为一个FAE，在这里也和大家分享点室内定位一些要点：

1.不管是wifi定位还是基站定位，只能当作室内定位的补充。

在成本可控的情况下，不能只依靠它两做室内定位，会出现偏差较大的情况，wifi定位在我曾经的几次在上海路测时候，出现过不少的错误数据，有给我定位到合肥的多个点，也有给我定位到北京的点，合理怀疑是WiFi信号源从上海挪到了合肥或者北京，也有可能是wifi信息被造假了，基站也有

2.一般来说，室内定位为蓝牙芯片+蓝牙信标，放置几个蓝牙信标在需要定位的场所，然后蓝牙芯片根据搜到的蓝牙信标的信号强弱，大概判断出来位置，lora也可以做此类应用。

3.如果需要室内高精度定位，如地下停车场寻车这种场景，一般的解决方案为UWB定位，可以实现室内厘米级别定位，当然，此种方式成本较高，需要购买UWB基站和UWB设备。

Air201是合宙自研的一款高性能、低功耗的4G资产定位模组，有着功耗低，功能多，体积小，全球通等特点。

它集成了先进的通信技术、定位功能和数据处理能力，为用户提供稳定、可靠、高效的远程监控与追踪解决方案。无论是智能家居、工业监控还是物流追踪等领域，Air201都能发挥出色。

你有没有出现过类似的问题？怎么解决的？分享一下吧~