最近一个杭州的客户,使用合宙的 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都能发挥出色。
你有没有出现过类似的问题?怎么解决的?分享一下吧~
全部0条评论
快来发表一下你的评论吧 !