I am trying to interface the ZigBEE with the X-CTU software, but its saying ‘Unable to Communicate with the Modem’. I have tried all the standard baud rates in the drop down box but nothing is working. Also, the RSSI led is glowing constantly even when there’s no Zigbee in the area and the RX led is flashing at an interval or approximately 1sec. In the X-CTU software, when I set the baud rate to 9600 and click on the Terminal window, I see the ZigBEE sending these strange strings after almost every second,
Does this mean that I cannot configure them using the X-CTU?
No, any of the XBees can be tested, configured and updated with X-CTU.
why would Digi will pack them up with some special firmware?
Good question. But the serial output doesn't make sense. Do you have another explanation?
Another may be that these are not really Series 1 XBees.
I do admit that either of these are not a good possibility.
I am hoping that Steve may have an answer.
pranjalchaubey,
Can you post a picture of the Xbees you got?
Another possibility is that there is another 802.15.4 device within range that is transmitting data once a second. The RSSI LED is an indication that this may be true.
This still doesn’t explain why these XBees are not properly responding the the Test/Query button in X-CTU.
I have tried all the standard baud rates in the drop down box but nothing is working.
Did you also try every Baud rate with the Enable API box checked?
Also in the terminal window enable the ‘Show Hex’ and see if there are additional data bytes. If the XBee is set in API command mode then you should see the non-ASCII data of the API frame. Then post what you get.
Another possibility is that there is another 802.15.4 device within range that is transmitting data once a second. The RSSI LED is an indication that this may be true.
To test this place the XBee in a Faraday cage made from a small cardboard box covered with aluminum foil with the fiol connected to your PC’s chassis. This should block any external transmission from being received. If the Test string stops with the XBee in the Faraday cage then the text is coming from another transmitter. Now its just a transmitter hunt to find the source.
Another possibility is that there is another 802.15.4 device within range that is transmitting data once a second. The RSSI LED is an indication that this may be true.
This still doesn’t explain why these XBees are not properly responding the the Test/Query button in X-CTU.
The place where I do my experiments is really huge and mine is the only lab that has electronics inside. Only other thing transmitting stuff at 2.4GHz is a wireless internet router placed in an adjacent room (and my WiFi adapter). I switched off both when doing the experiments. Other than these, there's nothing wireless whatsoever with the possible exception of mobile phones.
Regarding the Faraday Cage experiment, looks like a neat method to find out if something else is transmitting. But, don’t you think that the module is not designed to pick just any 802.15.4 signal? Only similar modules pick up signals and all the modules are in my lab and I know that none of them were working. Also, I face no problems when I work with XBee Pro 900. They work just fine here.
The series 1 XBees use standard 802.15.4 and will receive any 802.15.4 protocol transmissions that use Broadcast addressing. That is the purpose of using a standard. The WiFi uses 802.11 protocols and will not be picked up by the XBee. I run both 802.15.4 XBees and WiFi (both on 2.4GHz) within a few feet (~1 meter) of each other without one picking up the other.
I see you are in University. I have been working in electronics for over 20 years.
When some thing is going on that is not understood then one needs to break down and test each possibility to confirm or eliminate them. That is why I suggest the Faraday cage. If the text stops being receiver when the XBee is in the Faraday cage then there IS another transmitter running 802.15.4.
802.15.4 can be used in many places that you would be unaware of. It could be used for the thermostats in the rooms, for power monitoring, monitoring the air conditioning units on the roof, heater system, lights, or for other things. The building maintenance staff may know if any of their equipment is wireless and can look up the technical documents.
You were spot on there, when these things receive stuff, X-CTU is not able to communicate with them meaning that there’s some hidden 802.15.4 Tx. I guess I need to talk to the maintenance people now.
Today again I tried to de-brick these things with the following settings
Modem - XB24
Function Set - XBEE 802.15.4
Version - 10E8
(Function Set and Version are automatically selected by the X-CTU when you select XB24 as the modem)
After the operation completed, I got the following message in the status bar of X-CTU
Getting modem type…Programming modem…OK No AT parameters to set Detected baud rate difference. Make sure PC and modem baud rate is set correctly Write Parameters…Complete
Baud Rate Difference…Now what does that indicates? (I chose 9600baud)
I did a few experiments with this unit again in the X-CTU Terminal.
It IS going in to command mode when I press +++ (I guess that means its not bricked)
I checked RSSI Levels (ATDB)…coming between 45-52 (92 being max possible)
I changed the Baud Rate to 57600 (ATBD6). Result, I started getting weird characters in the terminal instead of that .#GCT string. When I changed the baud setting in X-CTU to 57600, the good old .#GCT string continued.
Now the question is how come this hidden 802.15.4 source is transmitting data at multiple baud rates?
Somebody told me that only modules with similar node identifier strings can communicate with each other.
I changed the default NI string to ‘PRANJAL’. But still I am getting those .#GCT strings. Not sure whats happening here.
.#GCT07022011135727</COLOR>
One thing for sure, there is indeed some 802.15.4 Tx out here, because the second part of the string shows local time in 24Hr format. The possibility of this being a special firmware is now totally ruled out.
I took the module to my dorm, almost 2km away from the lab. The RSSI Led was not glowing here and the X-CTU communicated with the module without any problems whatsoever.
Firstly, Thanks to you Waltr…there’s surely something ‘out there’!
Secondly, as I have stated in my previous reply, I changed the Baud Rate and Node Identifier String but still the module was receiving those .#GCT strings. That means the hidden 802.15.4 Tx is kinda very sophisticated. I hope to discover this source in the next few days.
The Baud rate is only on the UART side of the XBee and any transmission (RF) will be send out of the XBee’s UART at the set Baud rate. Why 9600 then 56.7k? My guess is that the XBee’s Baud rate changed. The Over the Air transmission Rate to about 500kbs regardless of what the XBee’s UART is set to.
Since you can measure the RSSI level that may be helpful in tracking down about where the hidden transmitter may be. Attach a battery so you can walk around with the XBee while reading the RSSI level. It should be stronger if it gets closer to the source.
only modules with similar node identifier strings can communicate with each other.
There is also a "Broadcast" transmission mode that all receivers will pick up. See "Broadcast Mode" in the XBee doc.
I don’t know of a way to set an XBee to ignore these.
A solution may be to force your XBee’s on to a different RF channel. Read the channel being used (CH) and look up the 802.15.4 RF channel frequencies. Then chose a Channel that is far from the one the Hidden transmitter uses.
Another is the PAN ID, read up on it.
There is also an Energy Scan (ED) command that may be useful in determining which channel is clear enough for you to use. This will detect the presence of WiFi so be sure the WiFi router is on. Also check SC & AS commands.
There are other settings that may isolate your XBees from the hidden transmitter. Check the follow in the doc:
A1, A2, AS, ID, MY, ND and read the XBee doc for hints on how to exclude the hidden transmissions.
Got it…believe it or not, its NASA ‘out there’! :shock: :shock: :lol:
I talked with the building maintenance guys and they told me that there is a high power wireless transmitter on top of the ATC Tower (yeah, we have an 800m long air strip as part of the lab). Later I came to know that the thing above is a part of some ongoing experiment with NASA (yeah, the NASA we all know) which monitors weather (and a few more scientific stuff) by sending a beam of high power laser and UV light in the atmosphere and transmits the data directly to NASA people. Pretty amazing! (and its a $300k equipment!!!)
I am here for a last 14 months and had no idea that something like this was going on above my head!
I am attaching a few pics, have a look. That small (it looks small from that distance) wall marks the boundary of my lab (and that is just one part of the institute!). The place is really beautiful.
Ok I can’t upload the pics here, too big. Have a look at them here,
It is amusing to find out what hi-tech is near by. But working with RF devices tends to find some of this.
:) :)
waltr:
Have you gotten the XBees to work in the lab under all that NASA stuff?
Well the XBee Pro 900 work, probably because of them working at a different frequency.
Haven’t been able to get these Series 1s going so far. I’ll get time to work on them again sometime next week, then I’ll try to bring them ‘out’ of broadcast mode. I’ll try manipulating with all those parameters you have suggested.
I made the ZigBEEs (Series 1) work under the hidden source by simply enabling the AES Encryption. I did it long time back, forgot to put up the solution here, someone else suffering from a similar hidden transmitter problem now have a hint.
I have a feeling that enabling the AES encryption slows down the data rate, not sure though. Waltr might be able to shed some light on this. Also, the communication is two way as long as only the encryption is enabled, but as soon as I put in the AES Encryption Key (same key in both the modules) the communication becomes one way. Absolutely no idea why this happens. Can someone tell me what am I doing wrong here?
