# Rapidly changing channels **URL:** \ **Category:** XBee - 802.15.4\ **Created:** [April 28, 2009, 2:24pm UTC](https://forums.digi.com/t/rapidly-changing-channels/1275 "2009-04-28T14:24:24Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![enodev](https://avatars.discourse-cdn.com/v4/letter/e/ce7236/32.png) [@enodev](https://forums.digi.com/u/enodev)\ **Post date:** [April 28, 2009, 2:24pm UTC](https://forums.digi.com/t/rapidly-changing-channels/1275/1 "2009-04-28T14:24:24Z")
Hi, I’ve a couple of xbee modules and want to change channels each time I transmit a packet to mitigate multipath fading. The module is attached via an usb-serial adapter and test program is basically looping (script is attached) over set channel query channel tx16 some data wait for transmit status or timeout I expect for each packet a ack or cca return code but get one only for every 10th or so packet, even if I put high delays like 100 ms between the commands. Serial communication speed is 57.6k. I’d expect to get a status code each time I transmit the message? Thanks for any pointers. Message was edited by: enodev ---
**Author:** ![enodev](https://avatars.discourse-cdn.com/v4/letter/e/ce7236/32.png) [@enodev](https://forums.digi.com/u/enodev)\ **Post date:** [April 28, 2009, 2:31pm UTC](https://forums.digi.com/t/rapidly-changing-channels/1275/2 "2009-04-28T14:31:59Z")
after reading through the forum a bit I tried again with two stop bits and this seems to work far better. But now I sometimes get a modem status message with status 0x01 reporting a watchdog reset? The loop is running at about 20 Hz. I was hoping to push it to about 40 Hz as the channel switching time is about 9 ms? Would it help to use higher baud rates or does the module get even more unstable then? ---
**Author:** ![enodev](https://avatars.discourse-cdn.com/v4/letter/e/ce7236/32.png) [@enodev](https://forums.digi.com/u/enodev)\ **Post date:** [April 28, 2009, 4:03pm UTC](https://forums.digi.com/t/rapidly-changing-channels/1275/3 "2009-04-28T16:03:49Z")
Best results are with 57.6k,8N 2(!) stopbits . But sometimes the xbee just hangs for a second or two. Firmware 1084 works much better than 10C4 btw. This is all without a receiver or something - just trying to push out packet as fast and reliable as possible. It seems odd that the serial interface should be the limiting factor? With firmware 10C4 I can get the modem to hang indefinetely without the watchdog kicking in. Bad bug! ---
**Author:** ![johnf](https://avatars.discourse-cdn.com/v4/letter/j/848f3c/32.png) [@johnf](https://forums.digi.com/u/johnf)\ **Post date:** [April 28, 2009, 9:43pm UTC](https://forums.digi.com/t/rapidly-changing-channels/1275/4 "2009-04-28T21:43:31Z")
The Python code you posted sets the option byte in the tx packet to disable ACKs. Is that (part of?) the problem, or were you using a modified version of that code? Or have I simply misunderstood? ---
**Author:** ![Admin1](https://avatars.discourse-cdn.com/v4/letter/a/bbce88/32.png) [@Admin1](https://forums.digi.com/u/Admin1)\ **Post date:** [April 29, 2009, 2:44pm UTC](https://forums.digi.com/t/rapidly-changing-channels/1275/5 "2009-04-29T14:44:47Z")
Why are you using firmwares 10C4 and 1084? Current release on our support site is 10C8. Have you tried this version? Message was edited by: admin ---
**Author:** ![enodev](https://avatars.discourse-cdn.com/v4/letter/e/ce7236/32.png) [@enodev](https://forums.digi.com/u/enodev)\ **Post date:** [April 29, 2009, 6:55am UTC](https://forums.digi.com/t/rapidly-changing-channels/1275/6 "2009-04-29T06:55:28Z")
No, I disabled ACKs intentionally figuring, losing a packet or two is okay in this application. What I’m counting are TX-status messages (command id 0x89). I should get one for each TX message (0x00 or 0x01) but that only works reliable down to about 20 Hz. If I don’t switch channels in between packets I can get around 100 Hz - but with a bad jitter (ie. queue 5 packets, get 5 replies in a row). The thing is I could probably live with 20 Hz, but the radio just crashing/hanging in between for seconds is a real problem ☹ And the sad thing is, that it ‘just’ seems to be a problem of the serial interface of the xbee, reading the other threads here. ---
**Author:** ![enodev](https://avatars.discourse-cdn.com/v4/letter/e/ce7236/32.png) [@enodev](https://forums.digi.com/u/enodev)\ **Post date:** [April 29, 2009, 2:58pm UTC](https://forums.digi.com/t/rapidly-changing-channels/1275/7 "2009-04-29T14:58:54Z")
X-CTU from yesterday show 10cd as current which I can readily crash in less than a minute using the supplied test program. 1084 at least does a watchdog reset. ---
**Author:** ![enodev](https://avatars.discourse-cdn.com/v4/letter/e/ce7236/32.png) [@enodev](https://forums.digi.com/u/enodev)\ **Post date:** [April 29, 2009, 2:59pm UTC](https://forums.digi.com/t/rapidly-changing-channels/1275/8 "2009-04-29T14:59:58Z")
btw. where do I find 10E2 and 10C4. Is there a changelog available? ---
**Author:** ![Admin1](https://avatars.discourse-cdn.com/v4/letter/a/bbce88/32.png) [@Admin1](https://forums.digi.com/u/Admin1)\ **Post date:** [May 4, 2009, 4:41pm UTC](https://forums.digi.com/t/rapidly-changing-channels/1275/9 "2009-05-04T16:41:51Z")
I’m not sure where 10C4 comes from. Until this thread, I’d never heard of it (unless that was a typo). As for 10E2, this is a beta and not readily available.