Hello. Using firmware 10CD on Series 1 802.15.4 firmware the XBee is ignoring the DTR line on pin 9.
By spec, DTR is asserted with logic 0 and deasserted with logic 1. Therefore DTR is asserted with 0v and deasserted with 3.3v.
If I reset the XBee to the firmware defaults, then deassert pin 9 by tying it to 3.3v, the XBee happily ignores DTR and responds to +++ guard and AT commands.
This is not as I would expect. My expectation would be that the XBee would ignore all communications to it until DTR is asserted by typing pin 9 to 0v.
I see that using sleep mode (SM) 1 or 2 achieves something similar to my expectation of DTR. If I deassert it while it is outside command mode, it DOES ignore IO and deasserts CTS.
However, if I am in command mode and I deassert (3.3v) DTR/pin9, it does not enter sleep mode. Instead, it happily accepts and responds to commands. Only when command mode times out or I manually enter ATCN does it match my expectations including asserting CTS.
Can we have an update in future firmware which more closely aligns XBee behavior to a more strict DTR behavior? That it should ignore all communications including if it is in command mode?
Before you read further, please note that I’m responding in “devil’s advocate” mode. To put that another way: it’s an interesting question, and I’d like to know why there’s a pin labelled DTR at all. Maybe we can work it out together…
Comment 1: well, a question really. You say “by spec” - which spec is that? I can’t see in the Digi documentation anything about the use of this pin as a DTR line, except for reference to the use of the pin during programming of the device. I’d welcome a pointer, because I do try to collect together the information from different sources.
Comment 2: You say that DTR is asserted with logic 0 (0V). That seems odd, because that pin has a pullup resistor which is enabled by default. If the function of DTR is to be to enable or disable communication, then the default state should presumably be to enable communication. I think that’s the opposite polarity to what you said.
Comment 3: flow control is via the RTS and CTS signals on the XBee. I’m not sure why a third line would be useful. DTR has a meaning in the realms of serial modems, but I’m not so sure that it’s so relevant when the RS-232 standard is applied to other situations.
Comment 4: Wikipedia says of the DTR signal:
“Asserted by DTE to indicate that it is ready to be connected. If the DCE is a modem, this may “wake up” the modem, bringing it out of a power saving mode. This behaviour is seen quite often in modern PSTN and GSM modems. When this signal is de-asserted, the modem may return to its standby mode, immediately hanging up any calls in progress.”
Is this the behaviour you want? If not, then what exactly?
I was referring to rs232 spec. The names and behaviors of dtr, rts, cts along with reference to the rs-232 board in the dev kit suggests to me Digi is designing the XBee to closely align with rs232 behaviors. In the XBee OEM RF module product manual for v1.xCx w/ 802.15.4 protocol pages 7, 12, 13, and 31 all refer to DTR. You can d/l this at http://www.digi.com/products/wireless/point-multipoint/xbee-series1-moduledocs.jsp
By RS232 spec DTR is asserted logic 0. DTR meaning that at logic 0 the DTE (keyboard, computer, etc.) is “fired up and just about ready to go” and by indicating this to the modem/xbee/DCE allows it to get ready also. In the XBee’s case, since it is pulled up, then if DTR was by default recognized, that communications would NOT proceed. Exactly as I would want. For example, if the CPU, computer, keyboard isn’t connected, then I wouldn’t want the modem/Xbee to start acting like I (keyboard, cpu) was ready.
RTS and CTS do provide hardware flow control. DTR is, in a sense, the first line to assert saying “lets get ready to go, I’m online” and the RTS/CTS are used during the online state to manage flow. Many implementations drop the modem<->modem connection when DTR is deasserted (logic 1). Its the big switch! For example, one implementation of wireless technology might not power the transceiver unless DTR is asserted because there wouldn’t be anyone to do anything with data incoming nor anyone there to even send out data. Some wireless tech takes time to setup the connection, DTR can be that setup and then CTS/RTS to manage flow of that active connection.
My preference would be for the XBee to go into an immediate sleep/hibernate state when DTR is deasserted by default. And if not be default, then to update the (or create a new) SM mode to force the sleep/hibernate state even when it is in command mode. Why? Because it is the DTE that is deasserting and it is the DTE that would be talking in command mode. Therefore if the DTE goes out of its way to deassert DTR then it really must also mean it doesn’t want the DCE/modem to stay in the command mode.
In my case, I deassert DTR so that I can power down the XBee and then send some data on the shared TxRx lines that the Xbee wouldn’t understand. Also, the XBee’s internal circuitry (e.g. pullup resistors) when powered corrupt the electrical signal.