Qeng errors - when to use it

Hi there,

I would like to use the QENG command to get the Extended Coverage Level (ecl) for the device. And then transmit this value in the payload.

I get errors when the device wakes up from deep sleep via RTC. I believe this is to do with the restrictions on when QENG works … Must not be in Psm or connected states (something like this). So I am somewhat ouzzled where I should place this in my routine.

One idea is mayve, exit deep sleep, then check SIM, get apn, then check network status. Then if connected, wait for Rcc idle then send qeng then do send data? I’m using quecopen.

Hi James,

I’ve got the same issue.

It seems to be that this command has to be executed only when you get CSCON = 1.

If you are using QuecOpen, you will have to add a new function to get the URC +CSCON = 1. This new function has to be placed in the file ril_urc.c

If you query QENG at that moment you won’t get any error.

Wow thanks Oscar. Hopefully I’ll get this working in the near future. thanks for the tips.

1 Like

So I’m using the bc66. Ecl is mode 0 which says “When the module is in PSM state or no service state, the write command does not support =0,”.

When I exit deep sleep I assume the radio stays in Psm until cereg passed? IE registered. Would qeng mode 0 work at this point? Or I fear maybe I need to send data first before qeng 0 will work. Thoughts?

Incidentally, if I have to store data during deep sleep eg the last ecl value, how is this done?

Yes this worked. Use cscon and urc. Indeed, radio only exits Psm when a send has been requested and thus in my case where I am only sending a single packet I had to store the results to transmit on the next wake up.

Are you sending AT+CENG=0 immediately after the send message (AT+QISENDEX) command returns data?