Wireless programming of Arduino

I am using Xbee ZB modules, I think they are also referred to as Xbee 2.5. I connect to them using [Sparkfun Xbee Explorer Regulated that is either connected directly to an Arduino, or through a [FTDI Basic Breakout - 5V to a computer.

I want to be able to upload programs to the Arduino through the Xbee link without modifying the Arduino bootloader or the code used on the computer (Arduino IDE and avrdude on Ubuntu Linux).

[Limor’s tutorial is a bit difficult to implement since she uses the older Xbee modules and the settings are different and have different names in the newer modules that I am using.

[Nate’s tutorial here at Sparkfun uses modified code to make it work.

According to the product page for the XBee Explorer Regulated it is specifically designed for wireless bootloading (which I assume means uploading of code to an Arduino). There is a solderbridge than can be used to connect DIO3 and RTS, I have tested using a short wire instead. As far as I can tell DIO3 is connected to the header at the pin corresponding to the DTR on the FTDI Basic card.

Has anyone managed to get wireless uploading of code to an Arduino working with Xbee ZB/2.5 modules and without modifying any code? I have not yet.

/Johan Adler](http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=122)](Xbee Adapter - wireless Arduino programming)](http://www.sparkfun.com/commerce/product_info.php?products_id=9115)](SparkFun XBee Explorer Regulated - WRL-11373 - SparkFun Electronics)

It seems the 2.5 Series modems do not support wireless bootloading.

The 2.5’s don’t do the I/O line passing the same way as the series 1. the series 1 modems automatically assert the respective pin on the other modem, whereas the 2.5 sends a special data packet telling the other modem the state of its pins. the packet must be interpreted by another device on the other end, this means the passing of the reset line is not automatically handled by the 2.5 modems.

as far as i know this is a firmware difference, as the modems still have complete control over their pins, but i havent been able to flash them to the older firmware.

i found this out the hard way :frowning: should have done my research.

also note that the 2.5’s can do mesh networking, and the series 1 cannot.

Re series 1 and 2 - note also that series 2 must always run the overhead of ZigBee meshing, even if you don’t want/need it.

Sorry, maybe I should have added this information myself when I figured it out.

I also found that the 2.5/ZB series are not able to transparently transfer the state of I/O pins. It is possible to use the API mode to read and write I/O pins on a remote module, but that would not allow for transparent and automatic uploads of code to the Arduino platform.

One solution might be to use a third module in API mode, maybe the PAN coordinator, as a link. The Xbee connected to the PC could then send its data to the coordinator, which will also periodically poll the state of the PC modules I/O pins. The coordinator then relays all incoming data from the PC module to the Arduino module, and also transfers the state of the relevant I/O pins to it. Data coming from the Arduino module will be relayed the same way back to the PC module. Maybe it would work, and even if it did I think it would be something of a pain in the ***.

Another idea would be to have a microcontroller of some sort, an ATtiny or ATmega, maybe an Arduino, between the PC and the Xbee module on the PC side. This µC would do the communication with the PC (in case of an Arduino it could not be on the usual UART port that Arduino refers to as Serial, at least not with the DTR pin connected the usual way). It would also have to read the DTR pin from the PC connection, without using it for a reset. The Xbee module on the PC side would have to be in API mode, and the µC would use it to transfer all data in both directions and to toggle the relevant I/O pin of the remote Arduino’s Xbee module.

This second solution is the one that makes most sense to me. It would take a microcontroller converting data streams and I/O states to/from API format, and once it is constructed, programmed and working properly it could just sit there unnoticed. If one would bother to implement conversion of AT commands to API commands it would be possible to use it just as if it was a 2.5 module in AT mode, setting destination address with AT commands etc.