hi, I’m working with BC68-gv. but I can’t use psm. does not respond to all these commands: at+cpsms=1,10111111,00000001 cpsms? and cpsms=?. I use cfun=1, whether to convert to cfun=0 and when to call the cpsms= setting… but it is possible to register on the network or after transmission with the old timer 11100000. my operator and sim supports psm, the operator says, to fall asleep immediately, you need to pass a second timer to 0. and immediately the question is, if you do fall asleep, how do you wake up later, will it be enough to call coapopen?
(post deleted by author)
judging by the consumption, it can still switch to PSM mode. but no matter what timer I set the t3324, battery consumption occurs within 10-30sec after transmission, even if I set the timer to 2s. you can somehow force bc68-gv to psm mode, since I do not wait for messages from the server and I do not need to wait for iddle
After registering the network, go to
AT+CEREG=5
AT+CEREG?
Quectel_Mechanism and Application Reference for PSM and Sleep Mode of NB-IoT Module.pdf (693.1 KB)
refer to BC28
Cereg returned:
+CEREG:5,1,3DEW,063396CA,9,00000101,11000011
psm works, but it doesn’t go to sleep right away. I received from the network 10sec (bits 101), I see that after the transmission is completed and the coap is closed, the current consumption is 45mA, that he tries to contact for about 40 more seconds, maybe it’s RCC or idle for a long time, then falls asleep and consumes several mca. and the next connection is also now, wakes up normally, but falls asleep very much For a long time. I tried to forcibly close the connection, at+cnmpsd and At+cscon=0 then call at+npsmset=1 to put it to sleep, but it returns false. At+Cscon? returned 0,1. Sometimes, rarely falls asleep in 10 seconds, as indicated in cereg.
I suggest you provide the debug log in response. I have sent the obtained tools and instructions, please refer to them
where can I get the firmware and the message file.xml on bc68gvbar02a02?
Sorry, I sent the tools and manuals of debug log wrong, I sent them to you again.
here are the logs. there is the first connection after power supply and setting up bc68gv, then I fell asleep after 40 seconds and after 20 seconds I sent the data again and upon completion of sending, I went to sleep after about 50 seconds.
according to the logs that I sent, I see that the transition from iddle to psm will lead clearly in 10 seconds. but the time from the transmission of the last message to proto_rrc_releasing can be long. example in after timestamp 00:03:19.901903 No 00021414
the next time the modem woke up, it sent and fell asleep well, as I expect according to the psm timers. but unfortunately, this rarely happens.
in the second log, this is literally the next transfer, the transition from idle to psm happened quickly, as I expected
lv_export_log.zip (1.7 MB)
According to the debug log analysis you provided, the inactive timer configured on your radio network is 40s, which is a very long time, and the idle state time is 10s, which is also a very long time
Please optimize your program according to my advice
you run
AT+QCOAPCLOSE=0
delay 1-2s
then run
AT+CSCON=1
AT+NPING=8.8.8.8,12,60,0,1,0x400
AT+CPSMS=1,“11011111”,“00000001”
OR
AT+CPSMS=1,“11011111”,“00000000”
Hi, I can’t change the inactivity timer, isn’t it determined by the operator?
Iddle state timer, 10 sec is the operator’s recommendation, I tried changing it to 2 sec, yes, it shortened the time a little. It doesn’t work with timer 0.
I do it like this.
When turned on:
…
+CPSMS=1,11011111,00000001 ← I set 2 seconds before connecting to the network
+NPSMR=1 ← so that the modem would tell me when it goes to sleep
+CGATT=1 ← when the connection is established, timers will be sent
+CSCON=1 ← for notification when the network status changes
… get CCLK, get DNS, etc.
+COAPOPEN
…
+CNMPSD ← I inform you that there are no more transmissions (probably this is not necessary?)
+COAPCLOSE
After waking up, I do:
+CGATT? ← checking if there is a network
.. get CCLK, get DNS
+COAPOPEN
…
+CNMPSD
+COAPCLOSE
after the coapclose, CSCON= 0 almost always arrives after 7-10 seconds, and then the PCM goes to sleep correctly. But sometimes CSCON doesn’t arrive for 40 seconds. As I understand it, this is the organization of the network by the operator, and I cannot influence the inactive timer?
yes,The inactive timer is determined by the base station, and you can’t change it
you can try the method for RAI
I didn’t understand this method at first. NPING = 0x400 sends RAI
Thank you, I will definitely try
Release assistance indication
The UE may include this IE to inform the network whether
-
no further uplink and no further downlink data transmission is expected; or
-
only a single downlink data transmission (e.g. acknowledgement or response to uplink data) and no further uplink data transmission subsequent to the uplink data transmission is expected.
UE initiated transport of user data via the control plane
Upon receipt of a request to transfer user data via the control plane, if the UE is in EMM-CONNECTED mode, the UE initiates the procedure by sending the ESM DATA TRANSPORT message including the user data to be sent in the User data container IE (see example in figure 6.6.4.2.1). The length of the value part of the User data container IE should not exceed the link MTU size for the respective type of user data (IPv4, IPv6 or Non-IP). If the user data in the value part of the User data container IE is an Ethernet frame, then the length of the Ethernet frame payload should not exceed the Ethernet frame payload MTU size.
NOTE: The recommended maximum size for link MTU is 1358 octets to prevent fragmentation in the backbone network (see 3GPP TS 23.060 [74]). Depending on the network configuration, setting link MTU size to a value larger than 1358 octets could lead to inefficient core network implementation due to fragmentation.
If the UE is in EMM-IDLE mode, the UE initiates the procedure by sending the ESM DATA TRANSPORT message included in a CONTROL PLANE SERVICE REQUEST message.
Based on information provided by the upper layers, the UE may include a Release assistance indication IE in the ESM DATA TRANSPORT message to inform the network that
-
subsequent to the current uplink data transmission no further uplink or downlink data transmission (e.g. an acknowledgement or response) is expected; i.e. the upper layers indicated that data exchanges have completed with the current UL data transfer; or
-
subsequent to the current uplink data transmission only a single downlink data transmission and no further uplink data transmission is expected; i.e. the upper layers indicated that data exchanges will have completed with the next downlink data transmission.
When receiving the ESM DATA TRANSPORT message, the MME shall identify the PDN connection to the SCEF or to the PDN GW, based on the EPS bearer identity included in message, and forward the contents of the User data container IE accordingly. If the ESM DATA TRANSPORT message includes a Release assistance indication IE, then ESM layer indicates to the EMM layer to initiate release of the NAS signalling connection,
-
if the release assistance indication indicates that no further uplink and no further downlink data transmission subsequent to the uplink data transmission is expected; or
-
upon subsequent delivery of the next received downlink data transmission to the UE if the release assistance indication indicates that only a single downlink data transmission and no further uplink data transmission subsequent to the uplink data transmission is expected.