March 8, 2010
about 4 years ago
After some additional bad experience …
I thought the cyclic sleep was the problem, so I reprogrammed all 20 modules to lengthen out the sleep time … and that seemed to fix it. But, the next day, the modules did not work AGAIN .. a module which had been working happily as an end point started to miss transmissions. I decided to reprogram it as a ROUTER/END POINT to guarantee that it would not sleep. But XCTU would not work,but rather bricked the module, and all the other modules that had been reprogrammed. Maddenly, it “programs” the modules OK, but then on “resetting AT” it “loses communication”. This whole system has serious problems …. I’ve now wasted about 4 days trying to get the “easy” wireless to work …. I would be better off wiring up my own tranceivers using 2n2222’s.
I changed the =sleep timeout to 0xfffe, and that seemed to eliminate a lot of the problems … perhaps all them. Now I am wondering why XBEE would choose a default value for cyclic sleep timeout that wreaks havoc upon anyone trying to program these things for the first time ….
Thank you for the suggestion about cyclic sleep.
Series PRO 2 is BAAAAAD news … do a google on XBEE and “Lost communication” … the modem connection to the chips is very flakey. I managed to program a few of the two dozen chips I bought, but the rest stubbornly refuse to communicate. Tech Support at DIGI could only recomment downloading a new copy of XTCU and firmware … which did not solve the problem. This is the flakiest development item I have ever worked with … PICKIT, Arduino,etc. just work when you plug them in. This fails for no stated reason, works occasionally, then fails again.
YOU HAVE BEEN WARNED.
No public wish lists :(
Forgot your password?
No account? Register one!