Hi,
I am just ok open AT Programmer. I am having problem with Powering down the Q26 exterme unit.
I send data to server unig GPRS service and when i get power down command from server,
I close the TCP socket.
and send AT+W32K=1,0 using API from my firmware.
but it dosent decrease the power consumption…
Unfortunately I do not have access to DTR signal of UART1 and always remains high. According to Open AT guide, when we use AT+W32K=1,0 it ignores DTR signal so I was hoping that DTR sate would not matter.
Please help on reducing Q26 extreme power consumption using W32K.
Regards.
The W32K mode works (most of the time) with firmware 7.4a on the Q26 Extreme. When 7.42 and 7.43 was released, something went seriously south and the device needs to be reset in most cases after issuing the AT+W32K=1,0 command. (Many subsequent commands will simply respond with +CME ERROR:515)
This is an identified bug by SWI and a fix has already been identified for the next FW release, 7.44.
Hi Tyrone,
Can you tell how are you using W32K in your Open AT app?
I have tried it in 7.44 and 7.43 but it doesn’t work for me.
I’m using below command in one of the tasks.
adl_atCmdSend ( “AT+W32K=1,0”, ( adl_atRspHandler_t ) NULL, NULL );
But I find that the task keeps processing next instructions/commands rather than going to sleep.
I think when the W32K command is issued by any task, CPU should go into sleep mode irrespective of what other tasks might be doing. Is this correct?
I understand that GSM paging will wake-up the CPU or will not allow CPU to go into sleep mode.
Now I checked response of W32K command. The response is “OK”.
But the behaviour is same as before.
So my conclusion is that sleep is not working on my Q2686G module.
I think firmware has some bug. (Firmware I used: see above post.)
I’ve also had problems in getting the module into sleep mode using the W32k command. When I issue the at+w32k=1 command ,the module used to reply okay, but the power consumption did not change.
After much time puzzling, I came to the conclusion that it was a firmware bug. The issue seems to be with R7.4, R7.4a and R7.43. Upgrading to the latest version R7.44 fixed the problem.