First AT+WMTXPOWER or AT+WMRXPOWER after boot, fails - known bug?

Hi,

We notice, that after freshly booting our HL7692 module (has RHL769x.2.23.172400.201706231140.x7120m_1 firmware, that it came with), sometimes (maybe 1 time in 4), the first AT+WMTXPOWER command that we issue, does not elicit an OK response, and indeed is not acted upon (no RF transmission observed on Spectrum Analyser).

The second command, with perhaps different settings, is fine (OK response, and RF transmission observed on Spectrum Analyser). And if for the third command, we repeat the first command, that third command is now fine. We can then toggle, ad infintum, between those two commands. And all are fine. Here’s an example sequence:

AT+WMTXPOWER=1,3,19575,368,0
AT+WMTXPOWER=1,8,21625,368,0
OK
AT+WMTXPOWER=1,3,19575,368,0
OK
AT+WMTXPOWER=1,8,21625,368,0
OK
AT+WMTXPOWER=1,3,19575,368,0
OK
AT+WMTXPOWER=1,8,21625,368,0
OK
AT+WMTXPOWER=1,3,19575,368,0
OK
AT+WMTXPOWER=1,8,21625,368,0
OK

We do of course acknowledge that the manual (AirPrime_HL76xx_AT_Commands_Interface_Guide_Rev12_1.pdf) page 326 says the following about the AT+WMTXPOWER command: ‘The module must be restarted after using this command.’ That statement doesn’t actually appear to be true, in so far as subsequent commands elicit an OK response, and are acted upon (RF transmission observed on Spectrum Analyser). The key issue here, though, is that the first command after HL7692 boot, sometimes fails. Infact, sometimes, the first two commands fail.

The same happens if we boot and then issue an AT+WMRXPOWER command. Likewise, the first one or sometimes two AT+WMRXPOWER commands, fail. But subsequent ones are fine. Even, when we try the same command as that first failing one or two commands. Here’s an AT+WMRXPOWER command example sequence:

AT+WMRXPOWER=1,900,62,-109
AT+WMRXPOWER=1,1800,699,-108
+WMRXPOWER: -85.6
OK
AT+WMRXPOWER=1,900,62,-109
+WMRXPOWER: -84.4
OK
AT+WMRXPOWER=1,1800,699,-108
+WMRXPOWER: -85.6
OK
AT+WMRXPOWER=1,900,62,-109
+WMRXPOWER: -84.4
OK
AT+WMRXPOWER=1,1800,699,-108
+WMRXPOWER: -85.6
OK

Is this all a bug perhaps, with the 2.23 firmware ? A known one ? That is fixed in a later firmware version ? We see the latest presently is 2.27. The 2.27 release note makes no mention of the AT+WMTXPOWER or AT+WMRXPOWER commands. But what about other firmware versions, between 2.23 and 2.27 ? They are not available on the Sierra website, nor their releases notes. So who knows ?

If a bug with 2.23 firmware, is there some workaround ? We’ve tried, prior to issuing that first one or two AT+WMTXPOWER or AT+WMRXPOWER command,s the following, none worked: 1) Issuing a AT+WMTXPOWER=0 command. 2) Issuing a AT+WMRXPOWER=0 command. 3) Issuing both. 4) Issuing an ATI command. 5) Issuing an AT command. 6) Issuing just a carriage return.

Best regards,

David

Hi @david.king,

This problem may come from your tool that is used to send AT command. Could you please check if there was any character(may be a blank) come up after your module finished booting? If there is a character come up after rebooting, your first AT command will be not recognized by module.

I suggest using the latest firmware for the best practice.

Thanks,

Please help to tick Solution if your question is answered.

Hi Cherokee,

Many thanks for your speedy reply there. About characters that appear during boot, we get the below.

Àü
+SIM: 0

+KSUP: 2

The À appears on reset apply, the ü appears on reset remove (ie boot start). The +SIM: 0 appears after 12 seconds, and the +KSUP: 2 after another 0.3 seconds. The HL7692 is ready to accept commands after 13.2 seconds.

Indeed, when we then type eg ATI, only the TI is echoed back. If we do ATI again, we get:

ATI

HL7692

OK

About using the latest firmware, I’ve been unable to make the 2.27 installer work :frowning: The topic as below has the details. Do you have any insights ?

Best regards,

David

Hi Cherokee,

I see that Vianney has a suggestion, for how I might get the HL7692 firmware version 2.27 installer to work, to upgrade from the version 2.23 that our HL7692 came with. I’ll try that suggestion now.

Meanwhile, I’ve made a bit of a discovery, by experimenting, with why commands sometimes receive no response.

It’s looking like the HL7692 UART receive buffer, hardware or firmware, is occasionally being left with something within (could be whole previous message, could be partial message, perhaps the 0D at the end). Or, extraneous data is getting into the buffer.

A ‘workaround’ I’ve found, is before each command, to send a command comprising two CR characters. And then wait 40 ms, before sending the command I want. A wait of 35 ms or lower is found not to suffice.

Just one CR is found not to be enough. Nor is instead sending one or two CR characters at the start of each command (eg CR CR ATI3 CR). That certainly improves matters. But some unreliability remains.

Our transmit and receive pin signals, from MCU to the HL7692, look good, when we sniff with a comms monitor. We see the characters we expect.

We see no such problem when our MCU talks instead to an HL7800, using the same pins, with either HL7800 version 1.7.14 or 4.3.9.0 firmware. We see other problems with that firmware, but that’s another story.

Best regards,

David

Hi @david.king,

After you run installer with extension .exe, please press & hold reset button for 5-10 seconds then release it.

Thanks,

Please help to tick Solution if your question is answered

Hi Cherokee,

I’ll try. But I suspect that won’t work, given that the installer would appear to support USB connection only, from PC to HL7692, not UART connection as we have. See topic as below. In particular Vianney’s post just now.

Best regards,

David

Hi @david.king,

It seems that your module was in sleep mode. Please help to check “AT+KSLEEP?”. If value returns 1, you should set “AT+KSLEEP=2” to exit from sleep mode.

Thanks,

1 Like