XBee Pro Constantly Streaming Data

Projects Networking, Protocols, and Devices
1

I've used Series 1 XBees a fair bit with little to no trouble. But now I'm using the XBee Pro XSC (900 MHz) for a long-range project and noticing some odd behaviour.

I've plugged one in using an adapter (this one, plus an FTDI adapter, so level shifting and all that is taken care of) to my computer. For the moment, the other XBee is unconnected to anything (no power, comm, etc). Using X-CTU, I have set the ID (PAN) to 1234 instead of the default 3332, all other settings left alone. When I go to the X-CTU console, I am seeing a steady stream of data coming in, no matter what network I change the PAN to.

An example of what I see in the console, it seems to be steadily increasing, and just keeps on streaming, this is only a couple seconds at most of data (had to trim to fit in post):

What am I missing here?

30 30 30 30 30 42 31 46 0D
30 30 30 30 30 42 32 30 0D
30 30 30 30 30 42 32 31 0D
30 30 30 30 30 42 32 32 0D
30 30 30 30 30 42 32 33 0D
30 30 30 30 30 42 32 34 0D
30 30 30 30 30 42 32 35 0D
30 30 30 30 30 42 32 36 0D
30 30 30 30 30 42 32 37 0D
30 30 30 30 30 42 32 38 0D
30 30 30 30 30 42 32 39 0D
30 30 30 30 30 42 32 41 0D
30 30 30 30 30 42 32 42 0D
30 30 30 30 30 42 32 43 0D
30 30 30 30 30 42 32 44 0D
30 30 30 30 30 42 32 45 0D
30 30 30 30 30 42 32 46 0D
30 30 30 30 30 42 33 30 0D
30 30 30 30 30 42 33 31 0D
30 30 30 30 30 42 33 32 0D
30 30 30 30 30 42 33 33 0D
30 30 30 30 30 42 33 34 0D
30 30 30 30 30 42 33 35 0D
30 30 30 30 30 42 33 36 0D
30 30 30 30 30 42 33 37 0D
30 30 30 30 30 42 33 38 0D
30 30 30 30 30 42 33 39 0D
30 30 30 30 30 42 33 41 0D
30 30 30 30 30 42 33 42 0D
30 30 30 30 30 42 33 43 0D
30 30 30 30 30 42 33 44 0D
30 30 30 30 30 42 33 45 0D
30 30 30 30 30 42 33 46 0D
30 30 30 30 30 42 34 30 0D
30 30 30 30 30 42 34 31 0D
30 30 30 30 30 42 34 32 0D
30 30 30 30 30 42 34 33 0D
30 30 30 30 30 42 34 34 0D
30 30 30 30 30 42 34 35 0D
30 30 30 30 30 42 34 36 0D
30 30 30 30 30 42 34 37 0D
30 30 30 30 30 42 34 38 0D
30 30 30 30 30 42 34 39 0D
30 30 30 30 30 42 34 41 0D
30 30 30 30 30 42 34 42 0D
30 30 30 30 30 42 34 43 0D
30 30 30 30 30 42 34 44 0D
30 30 30 30 30 42 34 45 0D
30 30 30 30 30 42 34 46 0D
30 30 30 30 30 42 35 30 0D
30 30 30 30 30 42 35 31 0D
30 30 30 30 30 42 35 32 0D
30 30 30 30 30 42 35 33 0D
30 30 30 30 30 42 35 34 0D
30 30 30 30 30 42 35 35 0D
30 30 30 30 30 42 35 36 0D
30 30 30 30 30 42 35 37 0D
30 30 30 30 30 42 35 38 0D
30 30 30 30 30 42 35 39 0D
30 30 30 30 30 42 35 41 0D
30 30 30 30 30 42 35 42 0D
30 30 30 30 30 42 35 43 0D
30 30 30 30 30 42 35 44 0D
30 30 30 30 30 42 35 45 0D
30 30 30 30 30 42 35 46 0D
30 30 30 30 30 42 36 30 0D
30 30 30 30 30 42 36 31 0D
30 30 30 30 30 42 36 32 0D
30 30 30 30 30 42 36 33 0D
30 30 30 30 30 42 36 34 0D
30 30 30 30 30 42 36 35 0D
30 30 30 30 30 42 36 36 0D
30 30 30 30 30 42 36 37 0D
30 30 30 30 30 42 36 38 0D
30 30 30 30 30 42 36 39 0D
30 30 30 30 30 42 36 41 0D
30 30 30 30 30 42 36 42 0D
30 30 30 30 30 42 36 43 0D
30 30 30 30 30 42 36 44 0D
30 30 30 30 30 42 36 45 0D
30 30 30 30 30 42 36 46 0D
30 30 30 30 30 42 37 30 0D
30 30 30 30 30 42 37 31 0D
30 30 30 30 30 42 37 32 0D
30 30 30 30 30 42 37 33 0D
30 30 30 30 30 42 37 34 0D
30 30 30 30 30 42 37 35 0D
30 30 30 30 30 42 37 36 0D
30 30 30 30 30 42 37 37 0D
30 30 30 30 30 42 37 38 0D
30 30 30 30 30 42 37 39 0D
30 30 30 30 30 42 37 41 0D
30 30 30 30 30 42 37 42 0D
30 30 30 30 30 42 37 43 0D
30 30 30 30 30 42 37 44 0D
30 30 30 30 30 42 37 45 0D
30 30 30 30 30 42 37 46 0D
30 30 30 30 30 42 38 30 0D
30 30 30 30 30 42 38 31 0D
30 30 30 30 30 42 38 32 0D
30 30 30 30 30 42 38 33 0D
30 30 30 30 30 42 38 34 0D
30 30 30 30 30 42 38 35 0D
30 30 30 30 30 42 38 36 0D
30 30 30 30 30 42 38 37 0D
30 30 30 30 30 42 38 38 0D
30 30 30 30 30 42 38 39 0D
30 30 30 30 30 42 38 41 0D
30 30 30 30 30 42 38 42 0D
30 30 30 30 30 42 38 43 0D
30 30 30 30 30 42 38 44 0D
30 30 30 30 30 42 38 45 0D
30 30 30 30 30 42 38 46 0D
30 30 30 30 30 42 39 30 0D
30 30 30 30 30 42 39 31 0D
30 30 30 30 30 42 39 32 0D
30 30 30 30 30 42 39 33 0D
30 30 30 30 30 42 39 34 0D
30 30 30 30 30 42 39 35 0D
30 30 30 30 30 42 39 36 0D
30 30 30 30 30 42 39 37 0D
30 30 30 30 30 42 39 38 0D
30 30 30 30 30 42 39 39 0D
30 30 30 30 30 42 39 41 0D
30 30 30 30 30 42 39 42 0D
30 30 30 30 30 42 39 43 0D
30 30 30 30 30 42 39 44 0D
30 30 30 30 30 42 39 45 0D
30 30 30 30 30 42 39 46 0D
30 30 30 30 30 42 41 30 0D
30 30 30 30 30 42 41 31 0D
30 30 30 30 30 42 41 32 0D
30 30 30 30 30 42 41 33 0D
30 30 30 30 30 42 41 34 0D
30 30 30 30 30 42 41 35 0D
30 30 30 30 30 42 41 36 0D
30 30 30 30 30 42 41 37 0D
30 30 30 30 30 42 41 38 0D
30 30 30 30 30 42 41 39 0D
30 30 30 30 30 42 41 41 0D
30 30 30 30 30 42 41 42 0D
30 30 30 30 30 42 41 43 0D
30 30 30 30 30 42 41 44 0D
30 30 30 30 30 42 41 45 0D
30 30 30 30 30 42 41 46 0D
30 30 30 30 30 42 42 30 0D
30 30 30 30 30 42 42 31 0D
30 30 30 30 30 42 42 32 0D
30 30 30 30 30 42 42 33 0D
30 30 30 30 30 42 42 34 0D
30 30 30 30 30 42 42 35 0D
30 30 30 30 30 42 42 36 0D
30 30 30 30 30 42 42 37 0D
30 30 30 30 30 42 42 38 0D
30 30 30 30 30 42 42 39 0D
30 30 30 30 30 42 42 41 0D
30 30 30 30 30 42 42 42 0D
30 30 30 30 30 42 42 43 0D
30 30 30 30 30 42 42 44 0D
30 30 30 30 30 42 42 45 0D
30 30 30 30 30 42 42 46 0D
30 30 30 30 30 42 43 30 0D
30 30 30 30 30 42 43 31 0D
30 30 30 30 30 42 43 32 0D
30 30 30 30 30 42 43 33 0D
30 30 30 30 30 42 43 34 0D
30 30 30 30 30 42 43 35 0D
30 30 30 30 30 42 43 36 0D
30 30 30 30 30 42 43 37 0D
30 30 30 30 30 42 43 38 0D
30 30 30 30 30 42 43 39 0D
30 30 30 30 30 42 43 41 0D
30 30 30 30 30 42 43 42 0D
30 30 30 30 30 42 43 43 0D
30 30 30 30 30 42 43 44 0D
30 30 30 30 30 42 43 45 0D
30 30 30 30 30 42 43 46 0D
30 30 30 30 30 42 44 30 0D
30 30 30 30 30 42 44 31 0D
30 30 30 30 30 42 44 32 0D
30 30 30 30 30 42 44 33 0D
30 30 30 30 30 42 44 34 0D
30 30 30 30 30 42 44 35 0D
30 30 30 30 30 42 44 36 0D
30 30 30 30 30 42 44 37 0D
30 30 30 30 30 42 44 38 0D
30 30 30 30 30 42 44 39 0D
30 30 30 30 30 42 44 41 0D
30 30 30 30 30 42 44 42 0D
30 30 30 30 30 42 44 43 0D
30 30 30 30 30 42 44 44 0D
30 30 30 30 30 42 44 45 0D
30 30 30 30 30 42 44 46 0D
30 30 30 30 30 42 45 30 0D
30 30 30 30 30 42 45 31 0D
2

all other settings left alone.

But, you're not going to tell us what they are?

3

PaulS:

all other settings left alone.

But, you're not going to tell us what they are?

They're all default except the PAN, as I meant to say. Transparent mode, MY=FFFF, 9600 baud, etc. I attached the XML config.

profile_300C.xml (1.48 KB)

4

MY=FFFF

So, accept anything from anybody. Is that really what you want?

5

PaulS:

MY=FFFF

So, accept anything from anybody. Is that really what you want?

For the time being, yes. I've tried 5-6 different PANs and I always get the same pattern of data. I have also tried setting the MY to something else, which had the exact same result.

6

I've tried 5-6 different PANs and I always get the same pattern of data. I have also tried setting the MY to something else, which had the exact same result.

I'd suspect something electrically interfering with the XBees where you are, then. Could you try taking them somewhere else?

7

PaulS:
I'd suspect something electrically interfering with the XBees where you are, then. Could you try taking them somewhere else?

Could be. I would have thought that more likely if it was a 2.4GHz radio (there are 20+ wifi networks visible...) instead of 900MHz, but I'll give it a try tomorrow anyway.

8

PaulS:
I'd suspect something electrically interfering with the XBees where you are, then. Could you try taking them somewhere else?

No change whatsoever at a completely different (and less noisy) environment, and on a completely different computer. I even tried updating the firmware, and using a different adapter (which is the one I've used a lot with S1 xbees). The data is always the same continually increasing pattern. Looking at the console log (but not the hex view, which is what I linked in the original post), I noticed that the data is always an 8-digit hex number, increasing by 1 on each line (all the below is coming in in Red Text, which denotes received from the XBee):

0000047B
0000047C
0000047D
0000047E
0000047F
00000480
00000481
00000482
00000483
00000484
00000485
00000486
00000487
00000488
00000489
0000048A
0000048B
0000048C
0000048D
0000048E
0000048F
00000490
00000491
00000492
00000493
00000494
00000495
00000496
00000497
00000498
00000499
0000049A
0000049B
0000049C
0000049D
0000049E
0000049F
000004A0
000004A1
000004A2
000004A3
000004A4
000004A5
000004A6
000004A7
000004A8
000004A9
000004AA
000004AB
000004AC
000004AD
000004AE
000004AF
000004B0
000004B1
000004B2
000004B3
000004B4
000004B5
000004B6
000004B7
000004B8
000004B9
000004BA
000004BB
000004BC
000004BD
000004BE
000004BF
000004C0
000004C1
000004C2
000004C3
000004C4
000004C5
000004C6
000004C7
000004C8
000004C9
000004CA
000004CB
000004CC
000004CD
000004CE
000004CF
000004D0
000004D1
000004D2
000004D3
000004D4
000004D5
000004D6
000004D7
000004D8
000004D9
000004DA
000004DB
000004DC
000004DD
000004DE
000004DF
000004E0
000004E1
000004E2
000004E3
000004E4
000004E5
000004E6
000004E7
000004E8
000004E9
000004EA
000004EB
000004EC
000004ED
000004EE
000004EF
000004F0
000004F1
000004F2
000004F3
000004F4
000004F5
000004F6
000004F7
000004F8
000004F9
000004FA
000004FB
000004FC
000004FD
000004FE
000004FF
00000500
00000501
00000502
00000503
00000504
00000505
00000506
00000507
00000508
00000509

Since this is always happening identically, regardless of PAN, MY, physical environment, adapter used, etc, and on 2 different modules I suspect I am missing something completely here. My S1 Xbees (in API mode) do not exhibit this behavior.

FWIW, I have been using the new (v 6.1.0) X-CTU, which is quite a bit different at least on the GUI level from the 5.2.xx branch. These modules did at one time speak to each other fine (and likely still do, something I intend to try to duplicate tonight), as I was able to dump a raw GPS serial stream directly into one and see the data through the other connected to my computer and plotting on a GPS program. But I could see the constant data stream coming in around the NMEA sentences. This excessive data coming in is going to make my life difficult on the Arduino I plan to use one on, API mode would help to an extent, but I'd rather not go there.

Thoughts anyone?

9

This excessive data coming in is going to make my life difficult on the Arduino I plan to use one on, API mode would help to an extent, but I'd rather not go there.

I don't see that. It looks like an issue with X-CTU, to me.

10

madmattd:
Since this is always happening identically, regardless of PAN, MY, physical environment, adapter used, etc, and on 2 different modules I suspect I am missing something completely here. My S1 Xbees (in API mode) do not exhibit this behavior.

When you say you changed the physical environment exactly what did you do? The XBee XSC Pro has a 28 mile line of sight range so you could be picking up anything.

I only have Series 1 and 2 XBees but looking at the user guide I wonder if you changed the Preamble ID (HP) like the 900 MHz documentation says to do to restrict interference? On pg 33 at http://ftp1.digi.com/support/documentation/90002173_M.pdf it says:

The Preamble ID (HP) can be changed to make it so a group of radios will not interfere with another group of radios
in the same vicinity. The advantage of changing this parameter is that a receiving radio will not even lock into a
transmission of a transmitting radio that does not have the same ID.

It also says on Pg 32:

When a radio transmits, it sends out a repeated preamble pattern, a MAC header, optionally a network header, followed then by packet data. A receiving radio is able to scan all the channels to find a transmission during the preamble, then once it has locked into that it will attempt to receive the whole packet.

11

One other thing.... I've noticed that when I make parameter changes using the new XCTU program that sometimes those changes do not go over.

For example I made a change to D3 and MY at the same time and clicked the write radio setting button at the top to write all changes. However sometimes the changes did not always go through (and I am using the Digi dev board).

If I made the changes using the write to radio button next to the configuration parameter it did appear to work fine since it only write that particular parameter over.

So just make sure your changes did indeed go through.

12

PaulS:
I don't see that. It looks like an issue with X-CTU, to me.

I was hoping that was the case. But viewing the Serial Monitor with the XBee hooked up (through the BoB + FTDI at 9600Baud) shows the same garbage streaming through. Same result if I hook the XBee up to an Uno on pins 2 and 3 and using Software Serial to echo to the Serial Monitor. AT vs API mode also makes no difference.

When you say you changed the physical environment exactly what did you do? The XBee XSC Pro has a 28 mile line of sight range so you could be picking up anything.

What it means is I took it from home and brought it to work ~5-6 miles away. I'm only using the wire antenna models atm, and it's a dense urban environment, plus the building at work is death on wireless signals (steel roof, I only get 2 bars on cell phone inside by a window, 5 outside the same window, though I guess 900MHz will penetrate better).

So just make sure your changes did indeed go through.

Yea, they are saving fine. The settings show back up after un-plugging the XBee and closing X-CTU, and then reopening everything. Also there when I go to another computer and read them. I've only been changing one parameter at a time, and using the write button next to said parameter to write them, so I haven't used the upper button yet that sounds like it might be touchy. Otherwise I like the new X-CTU much better than the old version though.

Changing the Preamble ID (HP) didn't affect anything, but something else on that page you mentioned got me thinking:

When a radio is transmitting, it cannot receive packets. When a radio is not sleeping, it is either receiving or transmitting.

The data is perfectly sequential, and pauses whenever a TX is sent from the XBee, and then resumes where it left off. I wonder if what I am seeing is in fact normal behavior for these 900MHz devices based on the above quote from page 33. I played around with the sleep setting and confirmed that the data stops streaming in whenever the module is in sleep, and then continues where it stopped when it comes out of sleep. Some more research is now in order on my part.

I don't really like this behavior, as like I mentioned it will make parsing data received from the XBee onto the Arduino a pain. It will be possible to see data that matches what I might send without me having actually sent it to the remote device. More thinking on my part if this behavior is in fact as designed.

13

After looking at the specs of the new XBee Pro XSC 900 MHz I decided to get a couple. I'd like to see how well they perform. Should be in next week so I'll let you know if I experience the same issue.

14

Denbo:
After looking at the specs of the new XBee Pro XSC 900 MHz I decided to get a couple. I'd like to see how well they perform. Should be in next week so I'll let you know if I experience the same issue.

I've been really busy of late and haven't gotten to do much more work on this. I'll be interested to hear how you make out. Their specs are definitely appealing for a long-range RF connection, which is naturally what I need them for.

15

Ok just an FYI I received the same XBees today and hooked them up to a Digi XBIB dev board. Neither one of them exhibited what you saw.BUT.... when I hooked them up to an Adafruit Xbee connector like you did they acted exactly as you described.

The problem is the Digi 900MHz XBees have a different pin layout. Someone on the sparkfun forum had the same problem https://forum.sparkfun.com/viewtopic.php?p=148596#p148596

Here is the answer and how to fix it:

If you connect an XBee S3B module into a third-party interface board (such as the Sparkfun USB Explorer, or Parallax USB Adapter) you will be unable to communicate to the module using X-CTU. If you view the UART of the radio, you will notice a sequential series of numbers being generated. This is because several third-party interface boards have an LED connected to pin 6 of the XBee header. This LED provides an indicator for the RSSI (signal strength) for most XBees.

The XSC (S3B) and XSC (S3) modules have a slightly different pinout than the rest of the XBee product line. Pin 6 is used as a config line rather than an RSSI indicator. A legacy feature on the S3B is a diagnostic tool called "pitch mode", when the config line is pulled low during startup, it starts sequentially counting numbers and outputs it to the UART. This feature was originally used to perform a range test allows further backwards compatibility with the XStream radio.

Because an LED indicator is connected to this config line, the S3B module will enter pitch mode due to the pin being pulled low. There is no way to bypass this mode on the XBee itself. The best solution is to remove the current limiting resistor or LED on the interface board that is tied to pin 6, which will leave the pin unused. Please refer to the manufacturer's schematic of the interface board to locate these components.

The older XSC (S3) module should not be affected by this problem because it has a higher value internal pull-up resistor on that pin. One of the advantages of the XSC (S3B) versus the XSC (S3) is reduced current draw when the module is sleeping. In order to achieve the lowest sleep current possible, the pull-up resistors used are higher in value and cannot overcome the LED pulling the pin low.

Sincerely,

Digi Technical Support

16

Hey, that's awesome, thanks for finding that Denbo!

I guess I missed that page while searching around for a solution to this. That link also explains why the other XBee explorer (not sure of the brand) I borrowed while trying to figure this out didn't communicate well with X-CTU. That's an easy fix too, I'll just desolder the RSSI LED or its resistor on the Adafruit boards so I can use one hooked up to the computer to talk properly. I'm only using the usual 4 pins of TX, RX, 3V3, and GND on my final circuit board, and a simple echo test on that board seems to be clear of the garbage.

Glad it was something simple after all.

Interesting that I was able to communicate via X-CTU and query/change parameters (though I had trouble updating firmware), as that link suggests it shouldn't have worked at all. Whatever, I'll borrow the desoldering gun at work for a few minutes tomorrow and I should be good to go.

17

Great. I have a couple unsoldered adafruit XBee adapters that I will build sans LED to see how they work out as well.

Good luck.

18

I desoldered the top resistor on my Adafruit boards (the one connected to the Red RSSI LED) as it was easier to remove than the LED. X-CTU terminal is now clear of data. I've yet to do a send/receive test, but as they were talking before (albeit with the garbage data in between), I have confidence they will work fine now.

If you are building your boards from scratch, you might as well not put either component on (the RSSI LED and the top resistor).

19

Yes I have a couple of spares from Adafruit I have not built yet. I'll make them without the LED and resistor for the 900 MHz XBees

20

Hi madmattd

I’m wondering if you managed to resolve this issue in the end. I have experienced the same series of problems, and have not yet found a solution.

Unfortunately I haven’t been able to solve the issue by parsing, as the sequential data streaming from the receiving XBee seems to be interfering with the data sent from the transmitting XBee, (the incoming signal is interrupted fairly regularly). I’ve tested the radios in different environments, using both the sparkfun XBee explorer and XBee shield and the symptoms don’t appear to change - which to me suggests that the data might be being generated by the receiving XBee itself.

I’ve attempted to rewire the XBee as suggested (omitting pin 6); however, I used my sparkfun explorer and XBee shields as small-large pin breakout boards, so I assume that the XBee might have been firing up in the same way. I’ll order some 2mm 10pin sockets and try again. Any advice would be appreciated.