最近一個杭州的客戶，使用合宙的 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都能發揮出色。

你有沒有出現過類似的問題？怎么解決的？分享一下吧~

?