Xbee-PRO 3.3v or 3.0v

I heard from a friend that digi recommended that in future the voltage suppy to their xbee’s be 3.0 volts and not the 3.3 volts as there seems to be some associated problems with running at the higher voltage.
Can anyone confirm this for me or point me to any links - app notes.

I’ve been using xbee series 1 devices for a few of years, and 3.3V has worked just fine. I have not heard about anything related to an idea of reducing the voltage on the radio; std voltage for many devices is 3.3V, 5V, etc. Hopefully you’ll get some authoritative info on the forum.

Good Luck…

I have not heard that either.

I would think the RF power will drop, which might be ‘helpful’ if you only have a few nodes in a few square feet of space. That is one issue all RF systems suffer - if nodes are too close and too powerful, they ‘saturate’ the RX circuits & hear nothing useful.

However, I routinely run many ZigBee or DM2.4 nodes (all at 3.3v) with distances of 2-3 inches and have never seen an issue with this.

I remember something about this. It was in an old version of the product manual, and if I remember correctly it said that under certain circumstances the XBee would take more milliamps if the voltage supplied was above 3V.

Later versions of the product manual don’t mention this issue, so I imagine it’s an old problem that’s now fixed.

We are using the xbee-pro in our products for firing off fireworks. We do sometimes get some weird feedback for instance one client has the RX under or near some high voltage power lines and claims he had to get closer to the RX units because there was no response. He ended up being 10 metres away from the fireworks. So I did a test with 4 RX’s placed under a tower with HV power lines. I did a walk test up to 230 metres and the units functioned well with no issues. I was advise I may need to change the Channel parameter incase there was some interference form nearby WiFi. If there’s additional noise the xbee is picking up, does the buffer overfill and cause the xbee to crash. Or does the buffer reset itself. Were not sending long data streams, just the occasional “FC” of “00” etc.

The noise doesn’t cause a buffer problem because the XBee works much as a ‘Ethernet MAC’ does. The packets (valid or noise) arrives in a special 1-only buffer and is flushed the instant the chip decides it is not understandable (bad checksum, not correct protocol).

The Xbee ‘buffer’ only sees valid packets with the correct protocol details. So in a true noise case, the Xbee kind of thinks the world is ‘quiet’ (few valid packets arrive).

Changing on the fly is tough. You might want to design & document a ‘pre-big-bang’ test which could detect this and one-by-one try to push the remote off to a new channel.

What Im thinking of doing with the CH parameter is simply allow the end user to change this channel number ( 12 to 23 ) through a setup menu if they believe the current channel is affecting the range of the units…