Difference between revisions of "XBee RF Modules"
(Created page with " 2 XBee 3 XBee PRO 1 Board 9pin seriale per XBee/PRO Dove: scatola sul tavolo centrale") |
|||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| + | xBee modules are radio frequency (RF) transceivers: they're modules capable of sending and receiving data wirelessly between them using an standard communication protocol called ZigBee. The advantage of xBee's is that you don't need to understand the communication protocol to take advantage of there capabilities, you just branch the module to the RX TX pins in the Wiring board and you're ready to go. | ||
| − | + | They are mainly used to connect "PC like" modules and "microcontroller-like" modules. | |
| − | + | We are mainly using XBee Pro S2B modules. | |
| − | + | ||
| − | + | To begin you can follow this example: http://wiki.wiring.co/wiki/XBee | |
| + | |||
| + | Since you are probably using your xbee in the lab you will probably notice that there are some interferences with WIFIs. | ||
| + | If you have this kind of problem follow this: http://www.digi.com/wiki/developer/index.php/Channels,_Zigbee | ||
| + | |||
| + | If your XBee project is still not working, here’s some common mistakes that both beginners and experts make: | ||
| + | |||
| + | - Not using the latest firmware (especially if ATD0 or ATIR is giving an error)* | ||
| + | - No reference voltage to VREF pin on the 802.15.4 radios (analog and digital reads give wrong values) | ||
| + | - Forgetting that AT commands use hexadecimals | ||
| + | - Hitting return after +++ (or otherwise not respecting 1 second default guard time) | ||
| + | - Conversely, _not_ hitting return after an AT command | ||
| + | - Letting the XBee time out of command mode before issuing an AT command (you’ll know because you get no response) | ||
| + | - Forgetting to write the configuration to firmware with ATWR (unless your application configures the radio interactively) | ||
| + | - Not using ATRE (restore factory defaults) before re-configuring a previously used radio (previous settings lurk unless you manually reset them all) | ||
| + | - Looking for analog output on the analog input pins instead of pins 6 and 7 (P0, P1) | ||
| + | - Using a voltage regulator without decoupling capacitors (10uF on input, 1uF on output is good) | ||
| + | - Mixing up TX and RX pins (fastest way to check this is switch the wires and see if it starts working) | ||
| + | - Using ZigBee version (ZB Pro or ZNet 2.5) when 802.15.4 version would do just fine (if you don’t need to make a mesh network) | ||
| + | - Trying to read more than 1.2 Volts on the ZB Pro and ZNet 2.5 analog inputs (that’s the limit) | ||
| + | - Buying Pro radios when you don’t need them. (Cost more, bigger, use a lot more battery) | ||
| + | - Deciding the XBees are flaky. (You may not be using them correctly, but they are very reliable) | ||
| + | - Deciding an XBee is burned out when it’s set to a different baud rate (check ON and ASSC lights) | ||
| + | - Deciding an XBee is burned out when it is just sleeping (Check ON light to see if it blinks occasionally) | ||
| + | - Forgetting to supply power or ground (ON light may go on and ASSC light may blink but both will be significantly dimmer) | ||
| + | - Not contacting Digi sooner for support, especially if your radio seems dead or you keep getting an error you don’t understand. | ||
| + | |||
| + | XBee Arduino Mistakes | ||
| + | |||
| + | - Sending continuously without any delay (try 10ms delay) | ||
| + | - Not removing RX and TX connections before uploading code (Arduino will give an error) | ||
| + | - Not removing RX connection when reseting, if you are continuously receiving data. (Arduino will never reset) | ||
| + | |||
| + | XBee LilyPad Mistakes | ||
| + | |||
| + | - Hooking up more than 4 Volts to the 3.3V pin | ||
| + | - Using switches without pull-down resistors (but not if you use the internal pull-ups) | ||
| + | - Not using a pull-up or pull-down resistor on pins 5 and 7 (these don’t have internal pull-ups at all) | ||
| + | - Using sensors without voltage divider resistors (if your sensor needs that circuit) | ||
| + | - Using too-resistive conductive thread for power and ground (try fabric or wires) | ||
| + | |||
| + | * Windows and X-CTU are required for firmware upgrades | ||
Latest revision as of 16:20, 11 December 2014
xBee modules are radio frequency (RF) transceivers: they're modules capable of sending and receiving data wirelessly between them using an standard communication protocol called ZigBee. The advantage of xBee's is that you don't need to understand the communication protocol to take advantage of there capabilities, you just branch the module to the RX TX pins in the Wiring board and you're ready to go.
They are mainly used to connect "PC like" modules and "microcontroller-like" modules. We are mainly using XBee Pro S2B modules.
To begin you can follow this example: http://wiki.wiring.co/wiki/XBee
Since you are probably using your xbee in the lab you will probably notice that there are some interferences with WIFIs. If you have this kind of problem follow this: http://www.digi.com/wiki/developer/index.php/Channels,_Zigbee
If your XBee project is still not working, here’s some common mistakes that both beginners and experts make:
- Not using the latest firmware (especially if ATD0 or ATIR is giving an error)* - No reference voltage to VREF pin on the 802.15.4 radios (analog and digital reads give wrong values) - Forgetting that AT commands use hexadecimals - Hitting return after +++ (or otherwise not respecting 1 second default guard time) - Conversely, _not_ hitting return after an AT command - Letting the XBee time out of command mode before issuing an AT command (you’ll know because you get no response) - Forgetting to write the configuration to firmware with ATWR (unless your application configures the radio interactively) - Not using ATRE (restore factory defaults) before re-configuring a previously used radio (previous settings lurk unless you manually reset them all) - Looking for analog output on the analog input pins instead of pins 6 and 7 (P0, P1) - Using a voltage regulator without decoupling capacitors (10uF on input, 1uF on output is good) - Mixing up TX and RX pins (fastest way to check this is switch the wires and see if it starts working) - Using ZigBee version (ZB Pro or ZNet 2.5) when 802.15.4 version would do just fine (if you don’t need to make a mesh network) - Trying to read more than 1.2 Volts on the ZB Pro and ZNet 2.5 analog inputs (that’s the limit) - Buying Pro radios when you don’t need them. (Cost more, bigger, use a lot more battery) - Deciding the XBees are flaky. (You may not be using them correctly, but they are very reliable) - Deciding an XBee is burned out when it’s set to a different baud rate (check ON and ASSC lights) - Deciding an XBee is burned out when it is just sleeping (Check ON light to see if it blinks occasionally) - Forgetting to supply power or ground (ON light may go on and ASSC light may blink but both will be significantly dimmer) - Not contacting Digi sooner for support, especially if your radio seems dead or you keep getting an error you don’t understand.
XBee Arduino Mistakes
- Sending continuously without any delay (try 10ms delay) - Not removing RX and TX connections before uploading code (Arduino will give an error) - Not removing RX connection when reseting, if you are continuously receiving data. (Arduino will never reset)
XBee LilyPad Mistakes
- Hooking up more than 4 Volts to the 3.3V pin - Using switches without pull-down resistors (but not if you use the internal pull-ups) - Not using a pull-up or pull-down resistor on pins 5 and 7 (these don’t have internal pull-ups at all) - Using sensors without voltage divider resistors (if your sensor needs that circuit) - Using too-resistive conductive thread for power and ground (try fabric or wires)
- Windows and X-CTU are required for firmware upgrades
