![]() |
發(fā)布時間: 2019-6-20 23:52
正文摘要:先簡單說一下實驗?zāi)康陌。平時做項目或做一些小作品的時候需要用到時間,時間用的是STM32內(nèi)部的RTC,在精度要求不是特別高時這樣省去接外設(shè)時鐘模塊,省時省力。但我們都知道 ... |
本帖最后由 Linux— 于 2020-2-5 21:41 編輯 各位,我又找到了一種方法,數(shù)據(jù)手冊上提到的。封裝成函數(shù)就是這樣的,親測可用: 函數(shù)如下:
只要模塊注冊到了網(wǎng)絡(luò),一下子就同步到網(wǎng)絡(luò)了,GSM模塊內(nèi)部時間也自動對齊網(wǎng)絡(luò)時間了。模塊有信號能注冊到網(wǎng)絡(luò)的話一秒鐘就搞定了,還是很快的。調(diào)用的時候可以讓它循環(huán)執(zhí)行,若是不成功,設(shè)置失敗次數(shù)達(dá)到10次就跳出就好了。若是失敗的話估計就是在關(guān)閉網(wǎng)絡(luò)場景那一步,其他的沒啥問題。下面是我在串口調(diào)試助手顯示的內(nèi)容:
可以看到模塊剛開機(jī)初始化完成時內(nèi)部時間是2004年01月01日00時00分05秒,同步網(wǎng)絡(luò)后時間自動更新到當(dāng)前時間:2020年02月05日20時33分05秒 了。有興趣的各位不妨試試。 ![]() |
Linux— 發(fā)表于 2020-1-3 00:18 現(xiàn)在回頭看了下,其實用服務(wù)器那種方式還是很穩(wěn)的,只需要小小改動一下,在void Get_Sever_Time(void)函數(shù)下把所有USART2_RX_BUF改成AT_RecvBuffer就好了,克服了上文說的那些缺點,今晚測試過好多次了,沒有失敗過,每次都成功。而且連接服務(wù)器的速度其實是跟信號有關(guān)的,之前那個地方信號太弱了,導(dǎo)致連接速度比較慢,在信號好的地方一下子就連上了。還有,AT+CCLK?只是獲取模塊的內(nèi)部時間,斷電重新上電后還是要從網(wǎng)絡(luò)獲取時間同步進(jìn)去的,不然也是不準(zhǔn)的。此外,獲取網(wǎng)絡(luò)時間和日期也可以用GPRS基站定位,從返回的字符串中把時間數(shù)據(jù)解析出來就行了。這個方法我也測過了,是能用的,但對信號強(qiáng)度要求更高,不然網(wǎng)絡(luò)沒配置好的話也是定位不到進(jìn)而獲取不了數(shù)據(jù)的。 ![]() |
參與人數(shù) 1 | 黑幣 +30 | 收起 理由 |
---|---|---|
![]() | + 30 | 回帖助人的獎勵! |
lis。ss 發(fā)表于 2019-10-27 17:54 現(xiàn)在回頭看了下,你這個問題是串口2中斷接收沒處理好造成的。如果不想改中斷服務(wù)函數(shù)的話就在void Get_Sever_Time(void)函數(shù)下把所有USART2_RX_BUF改成AT_RecvBuffer可以解決此問題,而且再也不會出現(xiàn)上文提到的那些確定,我今晚用SIM800C測過好幾遍了,沒問題,很好用。你可以試下。 |
qq1182560902 發(fā)表于 2019-12-30 13:34 從SIM卡獲取妥妥的,服務(wù)器不穩(wěn)。 AT指令集你去查一下 AT+CCLK? |
獲取時間不穩(wěn)定嗎??SIM卡或者時間是怎么做的? |
lis。ss 發(fā)表于 2019-10-27 17:54 別用服務(wù)器的方式獲取了,不穩(wěn)定不可靠,老是莫名其妙出現(xiàn)奇奇怪怪的問題。用我說的第二種方法直接從SIM卡獲取時間吧 |
"TCP","time.nist.gov","13" 發(fā)完后回來數(shù)據(jù)是 IIII 這樣的,怎么回事?,之前成功過 |
Powered by 單片機(jī)教程網(wǎng)