I am using the BC66 for UDP transmit only (IP Mode). I am testing with the Vodafone network in the UK. Using the Quectel Evaluation Kit I have been measuring the power consumption during a UDP Transmit of 50 bytes. I have been using QCOM tool to send AT Commands. To exit PSM I use the PSM_EINT push button and then manually Run the commands in QCOM.
Top part is - PSM exit (large spike at 640mA), transmit pulses, re-enter PSM after some time
Bottom part - zoomed in on transmit pulses
I have two areas of concern:
Why is it taking 450ms to transmit 50 Bytes? I have no reference point, so is that rate what you would expect? It is longer than the on-air rate x 50 bytes and longer than our original estimates. I suppose even UDP has overhead but I didn’t think it would be this much. I have read about “NON-IP” mode being the next potential step to reduce this further - however Vodafone do not support this in the UK. Thank you for any reassurance you can provide.
What is the 8 seconds of current after the transmit pulses? My desire is for the BC66 to re-enter PSM as soon as possible. Indeed, the QCOM debug otput happen immediately (“PSM ENTER”) but the current shows otherwise. I have the following settings / AT COMMANDS sent:
press PSM_EINT button
AT+CPSMS=1,“00000000”,“00000000” #no active time before PSM? as Tx only
AT+QNBIOTRAI=1 #Release Assistance - one uplink packet only
AT+QISEND=0,50,“01234567890123456789012345678901234567890123456789”
(I have also tried with QIOPEN and QICLOSE around the send - made no difference). I also varried the payload from 5 bytes, 10 and 20 bytes.
It is almost like RAI is being ignored? And it is waiting for RRC idle? Does RAI require me to disable DRX / eDRX?
If you enable deep sleep enter message, I think the end of “unexpected” consumption after PSM enter will be the same moment as this message is generated.
AT+QCFG="dsevent",1
In m experience BC66 will not go to deep sleep sooner than 10 seconds after PSM_EINT. And “initlocktime” and “atlocktime” do not help. Nor does AT+QRELLOCK.
Thanks Rastik very interesting. Hopefully dsevent will save some power. My long term goal is to use quecopen so hopefully locktimes and/or qrellock will work. They certainly look like the right commands.
Did you have any views on whether my transmit pulse is excessively long or what one would expect?
dsevent will not help you directly, it will just make the investigation easier, as you’ll see the start of deep sleep. Your goal is to achive to get ENTER DEEPSLEEP immediately after ENTER PSM. And, of course, get ENTER PSM immediately after transmission, but you’ve already achieved that with RAI.
As for the TX time, could you query AT+QENG=2 before and after transmission? When you substract values of rxtime and txtime from these two events, what values you get? They are in units of 100ms.
What does AT+CESQ report?
Of course you are correct. Thanks for the suggestions. In these current times I can only test every week, my home doesn’t have coverage. So I will report back in about a week. Thanks again.
I did manage to get the module to deep sleep very quickly. Total awake time between 3 and 4s. I used Rai and initlocktime at the lowest value allowed (1?). This worked for both opencpu and standard A10 firmware.
Working with quectel we think it’s something to do with the UK network that causes the higher peak currents, which are at the top end of the datasheet.
Thanks for the support, and I’m about to post two more questions. Grateful for any support and time anyone can give.
I’m using too the BC66NA for UDP transmit only.
My BC66 enter in deep-sleep in no less than 6 seconds
after reception of SEND OK from modem, even if the
network accepts the request value 0 for active time
of timer T3324 and I have also used the command
AT+QRELLOCK after transmit command.
I have observed that deep sleep comes at the same
time as the reception of URC +CSCON: 0.
To notice that if I use AT+CSCON? to testing connection
status, I get mode 0 long before unsolicited +CSCON: 0.
Anyone have any suggestions to speed up entry into deep sleep?
Well that is great that deep sleep happens fast. That is fully optimised. So the “delay” is on the rest of the interaction. Part of that is just network time, which can be affected by poor antenna. Then it looks like you are using it in at command mode so that will probably add a bit of time Vs just coding the internal processor. If you look at the current consumption you’ll probably find that all of it is the actual send within the radio and so I would not worry about trying to get the power down further.
