Why does XCTU issue unsupported ATCF commands?

Question

Running XCTU ver 6.3.0 with a pair of 9XTEND modems in API mode.

I can remotely discover and issue AT read commands over the air, but when I attempt to write commands like ATPL1 (via XCTU) to the remote device, I get an error.

The problem is due to hex / binary confusion. XCTU is attempting to issue a remote ATCF command, which is not supported by the 9XTEND DIGIMESH firmware. And then it attempts to issue ATPL<0x31> instead of ATPL<0x01>.

So, why does XCTU think it can issue the unsupported ATCF command?

Any ideas?

Answer 1

While designing API frames in XCTU, you need to select ASCII tab "AT command" but Hex tab for "Parameter Value".

This is because AT commands are accepted in ASCII value while most of the parameter values (except parameters like "Node Identifier") are accepted as Hex by these devices.

Comments

I agree, when designing API frames manually, I need to use hex values (and have done so succesfully).But if I just use the XCTU user interface to update the values, it thinks it can use ascii values after first issuing the (unsupported ATCF) command.