Parameter errors on X-CTU + XBee Pro modules.

Using X-CTU, last version, to program XBee Pro 802.15.4 modules, and using 10A5 versíon, there are two problems:

1: The CCA parameter indicates a rabge of 0-0x50, but only numers >=0x24 can be entered. Any value below 0x24 throws an error when writing to contiguration to the module.

2: Using MAC mode 1: 802.15.4 NO ACKs,there is always an error on RR parameter (XBee Retryes).

Help. (Thank you).

Firmware version 10A5 is a bit old - try upgrading to 10C8 or 10CD and see whether the problems still appear. Let us know what happpens.

And by the way: what is the CCA parameter? For the 802.15.4 XBees, all parameters I know of have either two letters, or one letter and one digit.

Excuse the mistake: the parameter name is CA-CCA Threshold.

I upgraded the firmware version of the modules to version 10E2. Thus:

  1. Fixed the problem with the parameter CA. Indicated before that could be adjusted between 0 and 0x50, now says 24 to 0x50.

  2. There is still a problem with the parameter RR XBee-Retries. The range of possible inputs is said that from 0 to 0x6, but does not accept any value between 0 and 6. The error is: “Error setting AT parameters. Either parameter is not supported or value out of range. Check parameters view for parameters in error”. The parameter RR now contains “ERROR”.

Regards.

Regarding the RR issue, I’m running firmware 10c8 here, and I can set RR to any value from 0 to 6 without problems (using a local API command packet). If anyone who’s running 10e2 can check this setting, it may help.

There have been posts from Digi in this forum suggesting that the “latest” firmware for general use should be 10c8 or 10cd, and that 10e2 should not have been released. I know this is a lot of messing around, but you could try a downgrade to 10c8 or 10cd to see whether RR works better.

It might be worth looking at the value of the EA parameter (read-only) from time to time. It counts ACK failures, and I think the motivation for wanting to increase RR would be finding non-zero counts there.

If you still have trouble with RR, try posting here the exact packet you’re sending in order to set it.

I just set RR from 0-6 successfully using 10E2 firmware. Just for kicks I tried value of 7 (out of range), and even before trying to write the value in XCTU the field turned red because it was out of range. When I went ahead and wrote it anyway, I got an error. I then set it back to 6 and the field was green (valid parameter). I was able to write 6 and read the config just fine.

All other parameters of my module were at default for the 10E2 firmware for this test. My first step was hitting the “defaults” button, writing the 10E2 firmware, then setting RR to all values from 0 to 7. 0-6 successful, 7 was an error.

You can reproduce the error as follows:

  1. Restore the module to default settings (With firmware 10CD, or 10E2)
  2. RR parameter works correctly: accepts values from 0 to 6, entering 7 or 8, causes an error message.
  3. Change the MM-Mac Mode to 1-802.15.4 NO ACKs
  4. Write a 0 in the parameter RR
  5. Press the button “WRITE”. You get the error message.
  6. Click “WRITE” again. There is not new error message, but the “RR” parameter is red, and the RR field content is “ERROR”

And more:

  1. Change the MM-Mac Mode to 0-802.15.4 MAXSTREAM…
  2. Change the RR parameter to “0”
  3. Click “WRITE” button: you get the error message.
  4. Click “WRITE” again: There is not an error message. But the RR field “ERROR”
  5. Enter “0” again in RR field, an change field focus to other field.
  6. Click “WRITE”. There is not error message, and now the RR field shows “0”.

I think there is a problem with the firmware, as related.

Best Regards,

Manuel.

Ah, now I think I understand. I too can reproduce this - it’s just that I don’t think it’s a firmware error.

If you check the documentation for the MM command on page 47 of the 10cx product manual, it says that MAC mode disables the Digi header on the RF packet, and it also says that it disables the RR command. Well, actually it says that the presence of the Digi header enables the RR command, which amounts to the same thing. That’s logical, because the RR command (page 51) sets a bit in the Digi header so with the header absent there’s no point using RR.

You could argue that it should be possible to set the RR value even if it’s irrelevant, but the behaviour as it is seems consistent and deliberate.

I think you’re right.

But, I think it is wrong to indicate “ERROR”. If the “RR” is irrelevant if the “MM” is 1, then the “RR” should not be visible.

It is a problem of software quality.