I am trying to get a serial link going to a Roomba. I got a 3.3V regulator: LD1086V33 and confirmed that 3.3V is coming out of the regulator properly.
I am using the Parallax 32400 board to carry the XBee. I have used this to communicate between a STM8S Discovery board and a computer, both using the carrier. The STM8S discovery XBee was powered from the 3.3V on the discovery board and the computer used only the USB power. I have used this setup for awhile with no problems.
With the regulator circuit connected I plug in the DIN connector to the Roomba and after a couple connect/disconnect cycles the XBee no longer works. Only the Parallax board power LED lights up.
The XBee appears to get burned out from something in this regulator circuit coming from the Roomba, but the Parallax board comes through unharmed.
I am looking for the next step to take. If when plugging/unplugging the circuit would the regulator have a voltage spike that would cause damage to the XBee? The XBee must be very sensitive to something since all other electronics powered off of this 3.3V does not have any problems, only the XBee stops working.
Edit: I tried to reset, nothing happens. I have X-CTU and the serial port shows up fine, but it will not communicate with the XBee.
I read some other peoples projects that used regulators and there was no trouble.
Is it the regulator that I used? I did not see any crazy voltages on the multimeter I was using when connecting/disconnecting. I will look with a scope, but I don’t understand why the XBee would fry (2 of them total now) and the parallax board not.
I notice that the Xbee’s are now little heaters and the only function they serve is to get hot. I have connected some microcontrollers and sensor boards to the 3.3V and subjected them to the same connect/disconnect punishment and they do not fry. Why do the XBee’s have to fry?
WTF?
Edit 2: Additional info: I did not have any serial comm connected, only the 3.3V from the regulator to power the boards. I know the Roomba is 5V and the Xbee is 3.3, the level translator isn’t finished so I was just powering the board from the regulator.
I tried every reset/brick fix I could find, and none work.
I see this guy:
http://blog.lucaseckels.com/2009/04/01/xbee-adapter-for-roomba/
used a 317T regulator, so I will add that to the next order as well and start the next design from that. It still does not make ANY sense why the XBee’s are getting fried while anything else connected to that EXACT SAME 3.3V works with no trouble…
Edit 3: Would using a 3.6V zener to clip any high voltage transients help? My current plan is to install a switch between the XBee and regulator so that I can turn the XBee on only after the regulator has stabalized, and off before disconnecting power to the regulator. If this solves the problem then the regulator is doing something strange. This is not an acceptable long term solution. If the problem is isolated to the regulator throwing a strange voltage somewhere then I am hoping using a zener to clip these voltages will be enough to protect the XBee.
The only other thing I can thing of at this moment is that with the filter caps on the regulator the voltage increases/decreases at a slower rate and maybe this transient voltage pattern causes the XBee to fry? Someone at digi needs to read a book on robust product design. (Whatever I am doing may be an edge case, but other products are working fine and do not fail) It is SO frustrating to run into a problem that noone else has had, and have no clear direction on how to solve it. My next digi-key order is going to be XBee modules and regulators. And at the rate I am going a small fortune will need to be spend on XBees.
Edit 4: My final conclusion at this point is that when the DIN connector to the regulator is pulled from the Roomba, the voltage transients from 3.3V to zero. It is slow enough that I can watch the progression on the multi meter. In the steady state with everything connected the XBee will happily show its power light and flash the LED on board. All hell breaks loose only on disconnect/reconnect. I am assuming the board self-initializes on power up, and this initialization would only happen once an acceptable voltage has been reached. On disconnect the internal circuitry tries to compensate for the reducing voltage to the point of frying itself (drawing too much current at some point?)
The other regulators don’t have this problem because either they somehow switch to zero quickly or are small enough that by being small they fall to zero quickly.
I guess I am going to start digging for any documenation from Digi on power supply design recommendations for these. I know there are smart power management IC’s that will allow for detection and control of power supply conditions to stage the power up of devices on board. If I was to build a product with XBee’s I would be seriously concerned about the reliability and robustness of the product when using simple voltage regulators, it took a few cycles with my setup to fry them, a regulator with more favorable conditions may appear to work, but after 100 cycles the XBee failure may show up.
The reason other 3.3V supplied boards are not failing is because they have been tested or designed for being supplied from a simple regulator and the voltage transients are handled correctly.
To prove/disprove this theory I am going to measure the dv/dt with a working XBee load connected to my current setup, and the previous setup that worked with no problems for me. I can then use a switch (dv/dt very high) and add in capacitors (dv/dt approaching my Roomba setup) and see at what point failure occurs if any. (Maybe power up sequence is really what is doing it in)
Maybe there is a doc somewhere I am going to find that outlines this mode of failure and these tests will be unnecessary.
The only other thing I can test for is as I mentioned before is over-voltage conditions on connect/disconnect. I can’t see this being an issue though because all other 3.3V dev boards connected (including the parallax FTDI adapter that the Xbee is riding on) do not show any problems.
Someone else has to have run into this though I suspect with all the prototyping going on?