I have a remote Xbee that is used to transmit analog signals from a gyro. The 2 gyro signals are connected to ADC/DIO1 and ADC/DIO2.
Before the Xbee is connected to the gyro, i changed the settings using X-CTU. Then I set it on the gyro board and transmit whatever analog signals to my pc via another xbee connected to a usb explorer.
The transmission seems to be fine. I wrote a vb program to capture the data from the serial port.
The problem is when i want to adjust the settings of the remote xbee, it doesn’t communicate with X-CTU anymore.
It has this message when I do a Test / Query:
Communication with modem OK
Modem type = Name unknown (ID = 4294967248525524)
Modem firmware version =
However I could still transmit signal when i put it back to the gyro board.
Settings I change: sampling rate (set to 50ms), D0 & D1 (set to 2 for ADC), Destination addresses to the Coordinator XBee.
Sleep is set at 0 - No sleep.
Baud rate was set at 9600, no change. I tried a few other baud rates (not all), didn’t work.
Yes it’s set for API and the Enable API box was checked.
I also found a post in DIY drones about ‘bricking’ XBees; the poster said powering up the XBee with power, ground and signal lines connected to the XBee could ‘brick’ the XBee. could that be possible? here’s the link: http://diydrones.com/profiles/blogs/one … -a-bricked
julrx:
It has this message when I do a Test / Query:
Communication with modem OK
Modem type = Name unknown (ID = 4294967248525524)
Modem firmware version =
However I could still transmit signal when i put it back to the gyro board.
Any help would be much appreciated!
I’ve seen such garbled ID when the baud rate is wrong, the baud rate error is more than about 5%, or the serial data electrical signal levels are marginal.
Which adapter board are you using between the XBee and the PC?
I assume that this worked originally. Re-check that it is connected the same as before.
Does the coordinator XBee talk to X-CTU?
Search through the treads here and there is info on ‘de-bricking’ XBees. If nothing is wrong with the hardware this might get the module talking with X-CTU.
My end device xbee could talk with X-CTU (using the usb explorer) while I am configuring it. Then i unplug it from the usb explorer and plug it to my pcb board with this gyro breakout board:
power it up, it transmits data to the coordinator xbee. But when I wanted to change the sampling rate of the end device xbee (using the usb explorer again) it doesn’t talk to X-CTU anymore.
So although i can ‘de-brick’ the xbee, how do i prevent it from becoming ‘bricked’? am i doing something wrong?
the thing is, although it doesn’t talk to X-CTU, it transmits data when plugged to the gyro board.
I have stuck to the same baud rate (9600) all the time.
You could send ‘remote commands’ to the end device through the coordinator in API mode. Study the API AT & Remote AT commands in section 6.0.4 of the data sheet.
I have another question, this time about the XBee USB explorer:
There are 2 ground pins on the USB explorer; if I power up an XBee on a USB explorer with a 3V battery, what is the difference between connecting the 3V battery to the 3.3V pin and to either GND pins?
I can’t really tell anything about your circuit. Could you sketch a schematic of the connections?
Which gyro is that (link please).
Also, I can’t seem to increase the sampling rate to 10ms (100Hz), it varies between around 16ms to 70ms but never at a steady value.
Is this sampling rate done by the XBee? If so I don't believe that XBees a meant to read and send analog data that fast, typical applications would be to sample every several seconds to many hours even though the sampling period can be set to 1ms. Trying to sample at too high a rate would get restricted by the ADC, packetizing, transmission and Acknowledge. Try increasing the sampling period until the received data matches the set sampling rate.
I can’t recall if the XBee firmware batches several samples in one transmission.
But a packet from an XBee 2.4GHz device will have many mSec of delay jitter. Some of the delay causes are:
Clear Channel Assessment (CCA), where a transmission is delayed due to other signals present, such as some WiFi packets. Hopefully not from analog signals like an analog wireless camera using the same spectrum (they’re about 6MHz wide; 802.15.4 is 2MHz)
Retransmissions by the MAC layer due to bit errors
Your application and/or XBee firmware delays.
(assuming no mesh network layer)
Trying to get a reliable datagram packet (w/MAC layer ACK) more often than about 20mSec, absent all CCA delays, is too idealistic.
So this depends on how many samples are packed into one data frame transmission. If you don’t like how the XBee default firmware packs samples, you can connect the XBee to a micro via a serial port (3.3V levels) and do your own packing and decision on when to try to sent. You’d code the samples with delta-time + sample datum in a batch. I’ve run the XBees at 115Kbps serial with a transmission every 20 mSec. You can also turn off MAC ACKs for these kind of transmissions, or transmit to the broadcast address which has no ACK, but this isn’t a good idea in general. The ACK time is about 0.2 mSec in 2.4GHz, for '15.4.
I very much wish that SparkFun would put a couple of sentences in the XBee product listings to tell people the differences between Series 1 and Series 2.
julrx:
maybe they think that putting EVERYTHING in perspective will take out the ‘fun’ for people (like me) who make tonnes of mistakes in their projects…
I started a thread here titled “Better XBee Documents”. Within are many links to documents and other info on the different XBees modules and protocols. Also, Digi International has much info on their web site about the different XBee modules and protocols. A quick search of the RF/wireles forum for “XBee” would find this thread!
By the way, I could not find any information on the Series 2 manual about Pin 14. Whereas the XBee breakout board refers to that as VREF. Any idea?
Since you are talking about a series 2 you bought from SparkFun I will Assume it is running the ZNET2.5 protocol (Series 2 can also run the ZigBee protocol and there is a different Digi Int document for each).
Pin 14 is listed in Table 1-02 as “Do not connect” in the Document “XBee™ ZNet 2.5/XBee-PRO™ ZNet 2.5 OEM RF Modules”, #90000866_C. This is different than on a series 1 module where this pin is the Vref input for the ADC on which the breakout board was based.
stevech:
I very much wish that SparkFun would put a couple of sentences in the XBee product listings to tell people the differences between Series 1 and Series 2.
There’s one sentence summaries on http://www.sparkfun.com/products/8687 and http://www.sparkfun.com/products/9132 but do you mean a better description than that? And do you think it should be on all XBee-related listings? If you would use different wording would you mind providing a suggested wording?
How can we petition them to do so?
If you provide some wording, I can I mention it to the guy in charge of product catalog.
