4G模组Air201—Wi-Fi定位问题——完美解决方案~

今天，我们将深入解决Air201模组的Wi-Fi定位功能中出现的问题，揭示其在物联网应用中的巨大潜力!

---

一、了解用户情况

我第一反应是，用户的定位流程可能有问题。让用户出示了两栋楼中对应的AT流程，流程如下：

一号楼AT流程：

五号楼AT流程：

看了一下，似乎也没有什么问题。
对比来看，两栋不同的楼栋，定位结果完全相同。

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

---

二、原理分析

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

实际上，Wi-Fi定位原理就是：

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

合宙使用的是高德的付费数据库，然后释放出来
——免费给用户使用！

知道了原理后，我指导用户，使用"AT+Wi-FiSCAN"这条指令，主动显示出周围的Wi-Fi信息。我拿着这些信息，手动去访问一下高德的定位库，看看是不是高德认为这两栋楼是同一个地方。

以下是用户两栋楼不同的Wi-Fi信息：

一号楼扫描到的Wi-Fi：

五号楼扫描到的Wi-Fi：

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

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

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

我想了又想，有没有可能：

高德使用的是GCJ坐标系，而经过我们服务器下发给用户的时候，由于用户习惯的坐标系不同，所以服务器经过GCJ坐标系转换成了WGS-84坐标系的dd.dddd格式。

是不是坐标转换或者格式转换的时候，丢失了精度？

于是我将上述两个经纬度，转换成了WGS-84坐标系的dd.dddd格式，再根据信号质量确定设备距离离对应的Wi-Fi信号源之间的大致距离。

完整代码请参见下方链接：

合宙GPS定位纠偏：
https://old.openluat.com/GPS-Offset.html

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

---

三、查看手册，找到答案

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

AT指令手册下载链接：
https://doc.openluat.com/article/4985

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

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

如果没有使用AT+Wi-FiLOC设置Wi-Fi定位优先，
则默认使用的是基站定位。

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

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

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

问题终于找到了！

---

四、问题解决 

和用户沟通后，用户使用AT+Wi-FiLOC指令，设置完Wi-Fi优先，再次去实地验证。

果然，定位结果不同了：

---

五、个人分享

问题解决了，用户很高兴！

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

▼ 室内定位要点 ▼

---

01. 不管是Wi-Fi定位，还是基站定位，只能当作室内定位的补充。

在成本可控的情况下，不能只依靠Wi-Fi定位/基站定位做室内定位，会出现偏差较大的情况。

个人实测经历：

在我曾经的几次上海路测，Wi-Fi定位出现过不少的错误数据，有给我定位到合肥的多个点，也有给我定位到北京的点。

合理怀疑是Wi-Fi信号源从上海挪到了合肥或者北京，也有可能是Wi-Fi信息被造假了，基站也可能有类似情况。

02. 一般来说，室内定位为蓝牙芯片+蓝牙信标：

放置几个蓝牙信标在需要定位的场所，然后蓝牙芯片根据搜到的蓝牙信标的信号强弱，大概判断出来位置。

LoRa也可以做此类应用。

03. 如果需要室内高精度定位：

如地下停车场寻车这种场景，一般的解决方案为UWB定位，可以实现室内厘米级别定位。

当然，此种方式成本较高，需要购买UWB基站和UWB设备。