Changing baudrate in API mode does not "bite"

XBee & XBee Gateway XBee - Zigbee
1

I have problem changing baudrate in API mode (Using XB24-ZB with FW=2341)
“AT-COMMAND” works fine but not for changing baudrate from the standard 9600 (=3) to something else.

  1. I send the new baud code. I.e Hex5
  2. I wait for my Tx buffer to become empty.
  3. I change processor baudrate (on local AVR CPU)
  4. I wait for frame mark hex7E, (but it never shows up)

In fact the Modem is completely silent so I guess my command was simply ignored.
Does anyone know if the obove is the correct sequence.
In other words. WHEN exactly is the baud rate change supposed to take effect? How long shall I wait?
Any clue is of interest…

2

Does your packet look like this:
7E 00 05 08 52 42 44 05 1A
If you are using a program other than X-CTU make sure you are sending the values as ASCII and not HEX.

3

I also agree that the information in the manuals are difficult to grasp. After several weeks I fell I’m still stumbling around in the dark and occasionally bump into something useful.

4

Thanks fordcf2000!

I found the error though. It had to do with my compiler which manipulated “nulls” in certain situations.

Having said that I would suggest to MaxStream, if they are listening to this forum, that they should give the manuals an overhaul. Some information is very rudimentary an leaves the user completely in the haze. As in this case.
There is not a word about what happens AFTER the commands are issued. What is supposed to happen when the BD-command has been sent?

  1. Shall we WAIT for the new baudrate to bite within certain time?
  2. Shall we expect the answer to come on the new or the old baudrate (Or BOTH, as some Bluetooth modules do)
  3. Will we get a reply message AT ALL?
  4. Are faulty messages reported as falty or simply ignored?

I suggest that each command type shall be described in a more structured manner. (but keep the current description type with flow-boxes too)
Each command should have:

  1. A Header with command name
  2. A verbal description of the purpose
  3. Description of all input parameters
  4. Description of the expected results
  5. Timing information
  6. exceptions
  7. Error handling
  8. Parameter format (Is leading zeros acceptable etc.)
  9. Other hints
    11.Crossreferences to related items
    12…

This would save us “grassroots” lots of trouble and sell more modules for MaxStream.
Reading this forum reveals quite a lot of frustration.
Obviously the functionality of hardware and firmware is fine, but still there are many implementers who give up due to shaky performance.
I strongly believe this has much to do with lack of relevant information, so please make the manual more informative!!! (Also add an index at he end of the book.
Finding a keyword is very difficult today)

/Per Svensson

5

i agreed, maxstream has very good module, but some of the documentation are not for the new ones, unexperience and or not well explain. Maybe they should add mode application note(sample source), which would encourage students(big market).