HL7800 - significant WMTXPOWER and WMRXPOWER malbehaviour with 4.3.9.0 firmware

IoT Modules HL78
1

Hi,

I’ve upgraded my HL7800 module, from the ‘BHL78xx.1.7.14.0.RK_02_00_00_00_87.20190103’ firmware it came with, to ‘HL78xx.4.3.9.0.RK_02_01_02_00_74.20200130’.

We now find though that functionality of the RF transmit and receive test commands AT+WMTXPOWER and AT+WMRXPOWER, have significant ‘malbehaviour’, as compared with the 1.7.14 firmware.

With the 1.7.14 firmware, the ‘only’ problem we saw, is that AT+WMTXPOWER=0 and AT+WMRXPOWER=0, to respectively disable RF transmit and receive, returned ERROR, but otherwise seemed to do their job.

In the 4.3.9.0 firmware, we see that problem is fixed. And indeed we see mention of the fix in the release note for 4.3.9.0 and indeed 3.7.2.3 firmware. Both release notes have the following to say about the commands:

DIZZY1-310
[WMTXPOWER] ERROR returns for AT+WMTXPOWER=0 and wrong response for read command

DIZZY1-265
[WMRXPOWER] ERROR returns for AT+WMRXPOWER= and wrong response for read command.

The 4.3.9.0 firmware though, has introduced to the AT+WMTXPOWER and AT+WMRXPOWER commands, four problems as below. They vary in significance. If you need, I can raise a separate topic for each of the four problems. With reference back to this one. Just let me know.

Best regards,

David

1 Echo back

Contrary to the ‘AirPrime - HL78xx - AT Commands Interface Guide - Rev10.pdf’ manual, write commands now echo back. Whereas the manual says they should respond just with OK, or ERROR if an invalid command.

Here’s five write command examples. For each, the first line is the command, the second is the undocumented echo back, and the third is the OK response. The 1.7.14 firmware didn’t do the echo back.

AT+WMTXPOWER=1,3,19575,2300,0,0<CR>
AT+WMTXPOWER=1,3,19575,2300,0,0<CR><CR><LF>
OK<CR><LF>

AT+WMTXPOWER=1,3,19575,2300,1<CR>
AT+WMTXPOWER=1,3,19575,2300,1<CR><CR><LF>
OK<CR><LF>

AT+WMTXPOWER=0<CR>
AT+WMTXPOWER=0<CR><CR><LF>
OK<CR><LF>

AT+WMRXPOWER=1,3,1575<CR>
AT+WMRXPOWER=1,3,1575<CR><CR><LF>
+WMRXPOWER: -154.0<CR><LF>

AT+WMRXPOWER=0<CR>
AT+WMRXPOWER=0<CR><CR><LF>
OK<CR><LF>

We note that the manual says about the ‘AT+WMTXPOWER’ command The module must be restarted after using this command. So we reboot the module before each command, and then only perform one command.

To mention though, we do notice that if we try performing a second, third, fourth etc command, behaviour is no different - sometimes commands work, sometimes they don’t, explained below.

2 Double <CR>

With reference to problem 1, note also the incorrect double <CR> in the echo back. Whereas the manual says as follows:

The "AT" or "at" prefix must be set at the beginning of each line. To terminate a command line, a <CR> character must be inserted. Commands are usually followed by a response that includes ‘<CR><LF><response><CR><LF>.

The response double <CR> can be ‘worked around’, by instead ending the command line with <CR><LF>. The firmware, 1.7.14 and 4.3.9.0, seems to tolerate, despite being contrary to the manual. We then get as follows, for the five examples given in problem 1. The 1.7.14 firmware works fine with ending any command lines with just <CR>, per the manual.

AT+WMTXPOWER=1,3,19575,2300,0,0<CR><LF>
AT+WMTXPOWER=1,3,19575,2300,0,0<CR><LF>
OK<CR><LF>

AT+WMTXPOWER=AT+WMTXPOWER=1,3,19575,2300,1<CR><LF>
AT+WMTXPOWER=AT+WMTXPOWER=1,3,19575,2300,1<CR><LF>
OK<CR><LF>

AT+WMTXPOWER=0<CR><LF>
AT+WMTXPOWER=0<CR><LF>
OK<CR><LF>

AT+WMRXPOWER=1,3,1575<CR><LF>
AT+WMRXPOWER=1,3,1575<CR><LF>
+WMRXPOWER: -154.0<CR><LF>

AT+WMRXPOWER=0<CR><LF>
AT+WMRXPOWER=0<CR><LF>
OK<CR><LF>

3 Command fail

AT+WMTXPOWER and AT+WMRXPOWER commands, instead of giving an OK response, often the exact same commands give an ERROR response. No receive power value for AT+WMRXPOWER commands. And no RF transmit for AT+WMTXPOWER commands, as observed on a Spectrum Analyser.

4 Silent treatment

Often the AT+WMTXPOWER and AT+WMRXPOWER commands give no response: No echo back. No OK. No ERROR. No receive power value for AT+WMRXPOWER commands. And no RF transmit for AT+WMTXPOWER commands, as observed on a Spectrum Analyser.

2

@david.king,

I have tried this and it all seems to work ok. Couple of points generically.

  • The echo you are seeing is probably down to the ATE setting, normally it is set to ATE1 so echo is on, you might have previously set it to ATE0 turning it off which is persistent. It could be that the upgrade reset it back to the default.
  • While I don’t have a spectrum analyser I have my bench power supply and when I send AT+WMTXPOWER=1,3,19575,2300,0,0 to the unit it consistently is drawing 400mA+ (where the dev kit is normally drawing 150mA ish in idle) imp[lying that it is transmitting blindly. After a power up I have not seen it not do this if the command returns OK. Obviously powering the unit off resets the mode and the unit comes up normally.
  • I suspect the command AT+WMTXPOWER=AT+WMTXPOWER=1,3,19575,2300,1 you have quoted is a typo? This, for obvious reasons returns +CME ERROR : 3.
  • Not seen a silent treatment.

Is the testing you are doing on your board/application or a development kit?

Regards

Matt

3

Hi Matt,

Many thanks for your speedy reply there. Some response below to your bullets:

  • Ah understood re the upgrade perhaps having reset to ATE1. I see a separate part of the code (not mine), includes ATE0 command issue, and I’ve perhaps not run that part, since upgrade. I’ll experiment on tomorrow. If echo is ATE1 caused, echo does seem to have different behaviour, depending on whether the command was blabla<CR> per the manual, or blabla<CR><LF>. For the former, command blabla<CR> is echoed, followed by <CR><LF> as for all responses, giving blabla<CR><CR><LF>. For the latter, command blabla<CR><LF> is echoed as-is, with nothing added.

  • Nothing to say on this

  • Oops, typo in my OP, now corrected.

  • Nothing to say on this

The testing is on our board

Regards,

David

4

Hi Matt,

On the first bullet, yes, seems the echo was due to ATE1.

Regarding the manual indication about the AT+WMTXPOWER command that The module must be restarted after using this command., does that mean via the HL7800 reset pin ? Is their an AT command ‘soft reset’ equivalent ?

If a reset is needed, it’s a lengthy 9 second wait for the HL7800 to reboot :-/ Is there such a thing as a ‘partial reset’ AT command, that would suffice, and doesn’t take so long ?

After an AT+WMTXPOWER=1,2,3.. command, is a reset needed even before doing:

AT+WMTXPOWER=4,5,6.. ?
AT+WMTXPOWER=0 then AT+WMTXPOWER=4,5,6... ?
AT+WMTXPOWER=0 then AT+WMRXPOWER=1,2,3... ?

In other words, after an AT+WMTXPOWER=1,2,3.. command, is a reset needed before any subsequent command, for that command to work correctly ? Or, is their any circumstance where a reset can be omitted ?

These questions to understand what functionality should work, so that I can tell which observed behaviours are ‘abnormal’. Also to understand what changes we may or may not need to make to our AT command interactions.

Thank you,

David

5

Hi Matt,

With HL7800 4.3.9.0 firmware, I’ve made a bit of a discovery, by experimenting:

If after issuing my first AT+WMTXPOWER=1,2,3 command since boot, if I want to switch to AT+WMTXPOWER=4,5,6, I can do so as follows, without needing to first reboot the HL7800:

  1. Issue AT+WMTXPOWER=0 command
  2. Wait 8 seconds
  3. Issue the AT+WMTXPOWER=4,5,6 command

If I wait only 7.5 seconds I receive ERROR response to the AT+WMTXPOWER=4,5,6 command, instead of OK

If I wait only 7 seconds, I receive no response to the AT+WMTXPOWER=4,5,6 command

Although I acknowledge that the manual indicates about the AT+WMTXPOWER command that The module must be restarted after using this command. , I’m intrigued:

What’s the HL7800 4.3.9.0 firmware doing internally, that makes this 8 second wait necessary ?
The 1.7.4 firmware didn’t need the AT+WMTXPOWER=0 command than wait.
Why the changed behaviour ?

Any insights you might have also on my previous message, would be gratefully received.

Best regards,

David