Rapidly changing channels

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

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?

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!

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?

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

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 :frowning: 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.

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.

btw. where do I find 10E2 and 10C4. Is there a changelog available?

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.