How to force RRC Connected

[spline_pete]

Custom board, ncs v1.5.0, modem FW v1.2.3, SES v5.34a. The code is based on the Asset Tracker (v1), LTE with PSM, motion-activated GPS, using MQTT to send messages to a private backend.

What's the leanest/quickest way to force RRC Connected so I can get accurate CESQ values, mainly RSRQ and RSRP?  I'm trying to avoid methods that send data, as this costs.  GPS operates during PSM, which means the CESQ values aren't valid during that time.  Once I have a fix, I want to get those values and add them to the packet.  Here's the idea:

if not RRC Connected, force it
send AT+CSCON?, wait for Connected
send AT+CESQ
get RSRQ, RSRP
return to PSM

[Didrik Rokhaug]

Hi,

I don't know if there are any ways to just set up an RRC connection without using that connection to send something.

But, you don't have to send data.

E.g. if you request new PSM parameters, that will cause the device to set up a RRC connection for the negotiation to take place.

Not that you have to request different parameters from what you currently are having, or the device won't do anything.

Best regards,

Didrik

[spline_pete]

Ok, I'll look into that.

Thanks.

[spline_pete]

I set new PSM parameters and then checked with AT+CSCON? each second for 30 seconds.  It never connects.

I tried dropping out of PSM with lte_lc_psm_req(false) and I think that did work, but the later  call lte_lc_psm_req(true) fails and that's bad for GPS.

[Didrik Rokhaug]

As you are using the LTE link control library, it might be better to register an event handler that handles the LTE_LC_EVT_RRC_UPDATE event rather than sending AT+CSCON? in a loop.

Changing the requested TAU period always triggered an RRC connection in my tests, but every LTE network behaves a bit differently.

There might be other AT commands that causes the modem to send something to the network that I missed, but requesting PSM and eDRX were the most obvious ones.

The other option is to send an IP packet of some kind, though it wouldn't have to be large. E.g. a small UDP packet.

Depending on how long your PSM intervals are, you might also want to consider AGPS. It will obviously add more cost in form of data downloaded, but in return you will get better GPS performance (faster fixes, fixes in worse conditions, better battery life). Once the GPS data is downloaded, you should also have your RSRP and RSRQ values.

[spline_pete]

Ah, yes. The event handler would be better.

I am using A-GPS, but it's only once/hour to minimize data usage.  I need something that can be used after every GPS fix.