XBee Hell

[liam.zbasic]

I've read several threads on XBee regarding downloads and now I'm concerned with bricking my ZX-40n device. It appears Xbee is not plug-n-play. I'm interested in the Xbee-Pro900 for long range downloads and communication. One of the Zbasic threads said something about baud rate switching as required by ZX, which Xbee cannot follow. Has this been reconciled in the latest IDE and all ZX devices including ZX-40n with a new single baud rate?

Can you summarize the required settings on the Xbee device to make downloading work reliability or perhaps an application note is in the works?

Is Xbee the most reliable approach for remote downloading? What does Elba Corp. use? Thank you.

[dkinzer]

One of the Zbasic threads said something about baud rate switching as required by ZX, which Xbee cannot follow.

That is correct. The XBee must be reconfigured for a different baud rate - it cannot be done using the same mechanism as a pure hardware serial channel. Since the IDE has no way to know that there is a radio link involved it cannot change the link's baud rate.

Has this been reconciled in the latest IDE and all ZX devices including ZX-40n with a new single baud rate?

If your ZX-40n has a bootloader v1.4 or later it implements the new semantics for ZXCmdMode() where False means "don't change speed when entering command mode. Together with the configuration of the IDE to also not change serial channel speed for downloading this should work for a radio link like XBee.

Can you summarize the required settings on the Xbee device to make downloading work reliability or perhaps an application note is in the works?

• Ensure that the bootloader version of your native mode device is v1.4 or later (use Register.BootVersion)
• Set the ATN character on the device
• Open the "Serial Port Options" dialog in the IDE and tick the checkbox for using ATN and untick the one below that for to prevent speed change for downloading; make sure the ATN character matches the one set on the ZX
• Set your radio link devices to the speed at which the ZX will operate (typically 19.2K baud)

[liam.zbasic]

Opting for the single baud rate simplifies the setup, but will ultimately result in slower download rates, which is why you have the baud switching in the first place?

The code below yielded "0102" for boot version, or v1.2, but you say I need v1.4 to be Xbee compliant. How much do you charge per chip to burn the latest ZX bootloader? I have both 40n and 328n devices.

Code: Select all

debug.print " Boot Version =" & cstrhex(Register.BootVersion)

Separately, is "bricking" really a possibility with wireless serial? My concern is that for longer ranges, losing a few bits is possible. That may be enough to derail the ZX program. But the wireless download will not alter the bootloader, right? And all I need is a hard serial connection to complete the intended download.

[dkinzer]

Opting for the single baud rate simplifies the setup, but will ultimately result in slower download rates, which is why you have the baud switching in the first place?

Yes, the higher baud rate for downloading reduces the time required for the downloading process. Since it is impossible (or, at least, impractical) to change the baud rate dynamically on a radio link device, the single baud rate makes downloading over the link possible. The highest rate I've successfully used on an Xbee device was 57.6k baud but that test was over a very short distance.

How much do you charge per chip to burn the latest ZX bootloader?

No charge. Just send them back (you can find the address on the "Contact Us" page).

Separately, is "bricking" really a possibility with wireless serial? [...] But the wireless download will not alter the bootloader, right?

Generally speaking, the risk of true "bricking" is low but an incomplete download could render the device incapable of responding to the ATN character.

If bits get dropped during transmission the device will send a negative acknowlegement due to CRC mismatch. This will cause the IDE to resend the corrupted record, which process will be repeated a number of times if necessary. If the multiple re-tries fail, the download will fail but the bootloader should remain intact allowing you to perform, if necessary, a download using the ATN signal.

[stevech]

Separately, is "bricking" really a possibility with wireless serial? My concern is that for longer ranges, losing a few bits is possible. That may be enough to derail the ZX program. But the wireless download will not alter the bootloader, right? And all I need is a hard serial connection to complete the intended download.

XBee's use IEEE 802.15.4 for the wireless protocol. It has an option you may set, using Digi's XCTU, to enable "MAC ACKs". If enabled, every packet sent will receive an ACK response from the receiving unit - at the MAC layer, transparently. If no ACK is received in x amount of time (a few tens of microseconds), the sender retransmits - up to 3 or more times (your choice), to do error correction. If this fails, the application protocol for bootloading will detect the error.

IEEE 802.15.4 is a reliable datagram service if MAC ACKs are enabled - much like IEEE 802.3 ethernet error detection. The bootloader application protocol can be thought of as akin to the IP or TCP layers with additional error checking.

Of course, any wireless medium will have from time to time, uncorrectable errors due to interference or too-weak signal conditions. Your solution implementation must cope by some means.

Note too the difference between the XBee series 1 (non-ZigBee) and series 2 (ZIgBee-focused). Rarely is ZigBee the best choice for simple applications.

I've used 802.15.4 and XBee (and others) for several years. It is the best choice for simple reliable short range wireless in 2.4GHz. WiFi is not a good choice unless you must have megabit rates. With the XBee PRO and/or some antenna gains, you can achieve 1/2 mile or more line of sight.

[liam.zbasic]

Is ZBasic compatible with Sparfun's Explorer USB (link below)? In a nutshell, its a breakout board for XBee modules complete with a voltage regulator and FT232RL chip for USB to serial UART communication. I never worked with USB or XBee, only PC serial connections. Will the ZBasic IDE see the USB device?

http://www.sparkfun.com/products/8687

[dkinzer]

Will the ZBasic IDE see the USB device?

If you install the "virtual serial port" driver for the FT232, that will create a COMx serial port that can be used by any application capable of using a serial port. There should be documentation accompanying the XBee Explorer describing how to install the drivers. Of course, if you have already installed the FT232 driver the XBee Explorer will be instantly recognized.

[stevech]

beware the diode-in-series-with-data design error in some of the SFE boards.

[liam.zbasic]

XBee's use IEEE 802.15.4 for the wireless protocol. It has an option you may set, using Digi's XCTU, to enable "MAC ACKs". If enabled, every packet sent will receive an ACK response from the receiving unit - at the MAC layer, transparently.

I definitely want to enable MAC ACKs. I have my Xbee Pro (XBP24) talking to Windows 7 X-CTU. There are four options for MAC Mode that I can set:

0 ~ 802.15.14 + MAXSTREAM HEADER W/ACKS
1 ~ 802.15.14 NO ACKS
2 ~ 802.15.14 WITH ACKS
3 ~ 802.15.14 + MAXSTREAM HEADER NO ACKS

The choice has to be "0" (default) or "2". Which is the best and most reliable option for ZBasic? Thanks.

[stevech]

#2 is what you want unless you are using MAXSTREAM/Digi's special modes such as virtual wire for I/O bit replication.

[liam.zbasic]

Thanks, option #2 it is (802.15.14 WITH ACKS).

I should've checked sparkfun's Xbee breakout board before buying it. See http://www.sparkfun.com/products/9132

The Xbee is a 3.3V device and not compatible with 5V mcu's. The sparkfun breakout board reconciels this with a simple diode - not very reliable as I gathered in these forums.

So I purchased Adafruit's breakout board too. See http://www.adafruit.com/products/126
Same price. That one handles level shifting properly with the 74AHC125N buffer.

[stevech]

It's not good that Sparkfun knows about but continues to sell that board with the diode in series with data to try to level-shift 5V. It's irresponsible. Most every customer posts that they can't get it to work and wastes time rediscovering the issue and solution.

[liam.zbasic]

The Adafruit XBee adapter kit arrived today and now I have a working wireless ZBasic setup. For those interested, I offer step-by-step instructions for point-to-point communication with two XBee Pro XBP24 modules between a ZX-40n device and a Windows 7 desktop:


STEP 1: Configure Xbee devices with X-CTU software.
--------------------------------------------------------------------
* Download X-CTU from:
http://www.digi.com/support/productdeta ... =utilities
* For those running 64-bit Windows 7, www.digi.com only offers a 32-bit version of X-CTU. Download it anyway. AFTER THE DOWNLOAD, RIGHT CLICK ON THE X-CTU ICON, SELECT PROPERTIES, SELECT THE COMPATIBILITY TAB, AND SELECT THE CHECKBOX CALLED "Run this program in compatibility mode for: Windows XP (Service Pack 3). This worked for my 64-bit system.
* Connect first XBee device to PC.
* Set "PAN ID"
* Set "MM-MAC MODE" to: Option 2 - 802.15.4 WITH ACKS
* Set "BAUD RATE". Start with 19200 (factory setting is 9600)
* Repeat process above for 2nd XBee. Make sure all settings exactly the same.
* In X-CTU, make sure XBee devices function properly by pushing the "Test/Query" button in the main "PC Settings" tab. Make sure baud rate is set to correct speed (19200 if you followed the settings above). Make sure you select the correct Com Port.

STEP 2: Configure ZX-40n with Hard Serial Line
-------------------------------------------------------------
* The steps below assume you have a working system with Windows, the ZBasic IDE, and the ZX chip. Steps also assume you have downloaded programs successfully on the host ZX chip.
* Make sure your ZX chip has bootloader v1.4 or later.
* Make sure your ZBasic IDE (v1.5.6) and compiler (v3.3) are up to date. The versions in paranthesis worked for me.
* Open the IDE.
* Open your ZBasic program that worked successfully with a hard serial line.
* Open "Serial Port Options"
* Select the "Use ATN Character" checkbox, select an ATN charater, AND UN-CHECK THE "CHANGE SPEED FOR DOWNLOAD" TO PREVENT SPEED CHANGE FOR DOWNLOADING. THIS IS REQUIRED BECAUSE XBEE DEVICES CAN NOT ADAPTIVELY CHANGE BAUD SPEEDS.
* Set Baud Rate to value programmed in XBee devices in STEP 1.
* Reminder: all steps up to this point are with the hard serial line. The is necessary in order to set the ATN character on the ZX chip via the compiled & downloaded program with settings above.

STEP 3: Re-Wire ZX-40n Device
------------------------------------------
* Disconnect power to ZX chip.
* Remove the MAX232 level shifter - its no longer needed!!!
* See http://www.zbasic.net/doc/ZX-40_Schematic.pdf
* Keep the 2N3904 transistor associated with the ATN signal.
* Also keep the pullup resistors for the ATN and TXD signals.
* Attach XBee device to Adafruit adapter kit ( http://adafruit.com/products/126 )
* Connect adapter kit +5V and GND to ZX power rail.
* Connect adapter kit RX pin to ZX-40n pin 14.
* Connect adapter kit TX pin to ZX-40n pin 15.
* Connect adapter kit DTR pin to ZX-40n pin 9 (again, 2N3904 transistor required)


STEP 4: Wireless ZBasic Communication
----------------------------------------------------
* Power up system.
* Open IDE
* Open "Serial Port Options" and select Port associated with other XBee device connected to PC.
* Make sure the settings in STEP2 still apply.
* Program and Download ZBasic programs as usual. Behind the scenes, it will happen wirelessly & seamlessly.


GOOD LUCK.

[stevech]

maybe now you wanna edit the thread's title?

Also... looks like that Adafruit board has LEDs that physically interfere with the larger size of the XBee Pro modules (60mW rather than 1mW). Perhaps just use different LEDs or mount differently.

[liam.zbasic]

Ah, good point regarding the XBee adapter kit. It's up to the user to solder the kit. The layout for the miniature LEDs is fine. The problem is interference (physical, not RF) with the XBee Pro board and the adapter kit transistor and capacitor. The Pro board (1-mile range) is larger than the standard Series 1 modules. Did not know this upfront. It was easy enough to bend away the transistor. On the other hand, the electrolytic capacitor leads tore off when I bent it. Luckily, Adafruit mistakingly sent two. Lesson here... plan out placement of transistor and e-capacitor before soldering.